Interface Mixins

[ducky64]

Infrastructural support for interface mixins - that is, the ability to add additional properties to an abstract block, e.g. RotaryEncoder with HasSwitch. Interface mixins can only be used on abstract classes, concrete classes may only be one class (but may implement multiple mixins, e.g. a single device can implement RotaryEncoder with HasSwitch)

In the Python HDL frontend, interface mixins are defined as a class. It does not inherit its base class, instead it declares its base class as a type parameterization. This is added into the superclass list on the proto. It's a bit inelegant structurally, but it allows the type checker and autocomplete to see the mixin fields only.

In the compiler, when it sees a unrefined mixin, the contents of the mixins are appended onto the (abstract) base class. This is only to support visualization - this will always produce an error, and the process may be unpredictable. Ultimately, it needs to be refined into a single use-defined concrete class, with the system checking for proper subclass relations.

On the proto side, this changes BlockLike's lib_elem to also have optional mixins as library references. Pre-refinement mixins are also stored in HierarchyBlock

Future PRs will refactor some existing library elements to use mixins, and will likely also need to improve on the infrastructure.
Examples:

• IoController with HasI2s (maybe even HasCan, HasUsb?)
• IoController with HasPowerSource, HasUsbPowerSource
• VoltageRegulator with HasEnable

Other refactoring:

• Adds super_superclasses to all elem proto types, which defines non-immediate superclasses. This enables refinement / superclass checks to not need the full library and can operate solely on the design tree.
  • Refactor the compiler to use these (where available, post-elaboration) instead of relying on library inheritance analysis. Pre-elaboration, the entire self-class+superclasses list are passed in
• Move subclass validation into DesignStructuralValidate - one step closer to eliminating stateful compiler errors (Create error expr type #223)
• Rename block_class -> self_class for consistency with other protos
• (unit testing) ElemBuilder add support for library composition
• Move scalafmt config into the compiler/ directory so it can be invoked from sbt

Potential future work:

• How can multiple mixins compose? e.g. what if IoController HasPowerSource and HasUsbPowerSource both have a ground?

Resolves #104