Better handling (design entry and visualization) for bridge and adapter pseudo-blocks

[ducky64]

Bridges are inferred by the HDL and pruned by the visualizer, so less of an issue right now. But some of the logic can probably be unified with adapter blocks or other similar constructs.

Adapters and other aggregation blocks (eg, voltage source merge blocks) are currently handled like normal blocks, and there is no special handling of them. Ideas and considerations:

• These pseudo-blocks need some way to be marked as such. Perhaps a superclass that the visualizer can use to interpret it as a block to be hidden.
  • Bridge blocks are currently (iirc?) detected by name matching, looking for (bridge). Instead, it should probably match on superclass.
• Adapter blocks should be 'inferred' from connections. Not sure what this would look like, but it should be more part of the port connect workflow than the block creation workflow. The adapter type should be inferred based on the ports being connected.
  • HDL for adapter blocks is currently styled different than block construction HDL, for example with Passive.as_analog_source or MergedAnalogSource.merge(self, port1, port2). There (currently) isn't a standard for this, and it's unclear how to detect and produce this stylized code. Should the IDE match on Port.as_* methods and infer adapters from those? What about other pseudo-blocks, perhaps some kind of method name matching along with super-class matching? Or some explicit user annotation the IDE can look for, eg class variable CREATE_FN = merge in MergedAnalogSource?
• Perhaps adapter blocks should be visualized separately, for example a stacked block (or circle, or triangle, or something) next to the port to indicate there is some adaptation going on. Unclear what multiple adapters might look like, or if it even should be allowed.