[reggen] Support optional downstream register and field attributes

[andreaskurth]

reggen already supports optional attributes for both registers and their fields. The list of permitted optional attributes currently is a list in the upstream code base. For integrators who want to define their own optional register and field attributes, this means they have to patch upstream code as they ingest it, which is not ideal.

To improve the situation for integrators, we can add a mechanism through which integrators can define additional optional attributes for reggen registers and register fields without having to modify any source code that is part of the upstream repository. Those attributes wouldn't be supported in any way by the upstream code (e.g., no code gets generated from them); the upstream code just wouldn't reject them (unless they clash with attributes defined upstream -- no guarantees on that).

[meisnere]

In addition for adding values to OPTIONAL_FIELDS inside field.py and register.py, I would also like to add values to OPTIONAL_FIELDS inside ip_block.py.

[engdoreis]

Would successfully running reggen after adding new fields to a HJSON file (for the field, register, and IP block) be a valid way to test this feature's completion?

[engdoreis]

I noticed that the supported attributes are declared as a hardcoded dictionary in the source code. The attribute declaration contains it's name and type, but the type doesn't seem to be verified anyway.
With that in mind, I have three approaches to suggest for this problem:

1. Remove the optional attribute checking, only check it the mandatory attributes are present.
   1.1. Mandatory attributes would have the same behaviour as today.
   1.2. Optional attributes would have the same behaviour as today.
   1.3. Additional optional attributes would be ignored by reggen, but no error would be emitted.

2. Like 1 but in 1.3 emitt an warning when a attribute is present but not supported.

3. Introduce a hjson file for adicional (vendor specific) attributes, pass it to regtool by an argument or environment variable.
   3.1 Mandatory fields would have the same behaviour as today.
   3.2 Optional attribute would have the same behaviour as today.
   3.3 Additional optional attribute would be ignored by reggen, if declared in the vendor_specific.hjson, otherwise an error would be emitted.

@rswarbrick @andreaskurth for visibility

[meisnere]

I think option 3 is the best, as it can spot typos while defining a vendor specific field.

[engdoreis]

This is a draft engdoreis#44

[meisnere]

Thank you @engdoreis.
@andreaskurth please decide which implementation is better for you. For me both are ok.

[andreaskurth]

Thanks @engdoreis and @meisnere; I agree with preferring option 3.

As to how to implement that (see this draft PR), I don't have a strong preference. Maybe @rswarbrick or @AlexJones0 can chime in with their expertise?