Feature idea: composite device grouping - wrap several elements in a boundary with external terminals

[ispyisail]

Checked: is this already done?

No, and — same caveat as the recent obstacle-routing proposal — this is a substantially bigger ask than most items in this tracker. Both structural prerequisites this needs are entirely absent from the object model today, not just unexposed in the UI.

What's missing, confirmed

• No general "group several elements" concept. QGraphicsItemGroup (Qt's own grouping primitive) is used exactly once in the whole codebase, for ElementTextItemGroup (elementtextitemgroup.h:35) — which groups an element's own text items, not elements themselves. There is no mechanism anywhere to take several independently-placed Elements on a diagram and treat them as one visual/logical unit.
• Terminals can't exist without an owning Element. Terminal's constructor is Terminal(TerminalData *data, Element *e = nullptr) (terminal.h:46) — every terminal is a child of some specific Element; there's no path to attach a terminal directly to a QetShapeItem (the plain rectangle/shape drawing tool, which itself has zero terminal or electrical-connectivity concept at all). So "terminals placed on a rectangle" can't mean a literal freestanding shape today — the rectangle itself would have to be an element for its border to carry real terminals.
• Net effect: neither "select several existing elements and wrap them" nor "put terminals on a plain shape" has any existing foothold to extend — this is new object-model work on both fronts, not a hidden/disconnected mechanism like most items in this tracker.

Proposed scope (staged, to keep this buildable)

• The boundary itself is a new element, not a plain shape — sized to the wrapped selection's bounding rect, with its own terminal parts on the border (reusing the ordinary element/terminal machinery rather than inventing a second kind of terminal).
• "Wrap selection" action: given a user's selection of already-placed elements, auto-detect which of their terminals have conductors leaving the selection's bounding box (the genuine external connection points) and generate one boundary terminal per such point, auto-wiring an internal conductor from each new boundary terminal to its corresponding wrapped element's terminal. The wrapped elements and their existing conductors are otherwise untouched — nothing about how connectivity actually works changes, this only adds an outer interface in front of it.
• Collapse/expand view: a toggle to hide the wrapped elements and their internal conductors, showing only the boundary and its terminals — a display-only convenience (visibility/z-order), not a change to what's actually connected to what.
• Explicitly not proposing a new electrical model or a change to how Conductor/Terminal connectivity fundamentally works — the boundary device is just an ordinary element with ordinary terminals and ordinary internal wiring; the novelty is entirely in the "wrap this selection and auto-generate + auto-wire the interface" tooling around it.

This is large enough that I'd want to align on the exact scope (does collapse/expand matter for a first cut, or is generate + auto-wire enough on its own?) before committing to an implementation.