[UR] Allow for extending enums

[veselypeta]

Method to extend existing enums:

• Introduces a new yaml syntax - enum can now include and extend field to indicate that this extends an existing enum
• When parsing this new type, it inserts all the etors into already existing etor
• We have to manually refresh the meta data structure - to ensure downstream changes as picked up such as validation/loader etc.

Closes #606

[kbenzie]

Once the design is done it should be documented in scripts/core/CONTRIB.rst and the YaML.md.

[kbenzie]

LGTM - minor comments

[veselypeta]

Another idea I had. Instead of requiring every extended enum to provide a unique value - we could just specify a starting range.
i.e.

type: 'enum'
name: $x_device_info_t
desc: "a desc"
extended: true
offset: "0x1000"
etors:
  - name: "ETOR_1"
    desc: "desc"
  - name: "ETOR_2"
    desc: "desc 2"

So enums will automatically be allocated sequentially

[pbalcer]

Another idea I had. Instead of requiring every extended enum to provide a unique value - we could just specify a starting range. i.e.

type: 'enum'
name: $x_device_info_t
desc: "a desc"
extended: true
offset: "0x1000"
etors:
  - name: "ETOR_1"
    desc: "desc"
  - name: "ETOR_2"
    desc: "desc 2"

So enums will automatically be allocated sequentially

Do the specific values matter? If not, would it be possible to, for example, automatically allocate ranges for new extensions from the top of the enum's range? e.g.,

enum FOO {
   FOO_OPTION_A = 1,
   FOO_OPTION_B = 2,
    ....

   EXT2_OPTION_A,
   EXT2_OPTION_B,
   EXT1_OPTION_A,
   EXT1_OPTION_B,
   MAX = UINT32_MAX,
};

[veselypeta]

Do the specific values matter? If not, would it be possible to, for example, automatically allocate ranges for new extensions from the top of the enum's range? e.g.,

I don't think so, but I think that assigning values could be problematic. Possibly adding a new experimental feature might change the order in which they are allocated and modify the range.

[veselypeta]

I've decided not to introduce offset or automatically allocating experimental feature ranges yet, instead enforcing that each etor must have a unique value. I feel like we can easily iterate on this and add this at a later point.