Blackbox IO doesn't actually "exist"

Related: #249 and #282.

The root cause of both issues is that the BlackBox IO object itself doesn't actually get emitted as FIRRTL, only its children are. So operations on that IO object would become invalid if emitted to FIRRTL, and any properties of it (like flipped-ness) are dropped.

The second is possible to fix by special-case logic in the emitter, and the first is (probably?) already worked around by resolving bulk-connects at the Element (leaf) level in Chisel. But the underlying issue is still there, and if we ever start emitting bulk connects again it will break.

Potential solutions:
- More and more special casing. Very ugly, high likelihood of missed edge cases and bugs.
- Deprecate the "legacy" `BlackBox` interface in favor of `ExtModule`, which supports multiple top-level IO objects and doesn't do this special IO unwrapping. Possibly also introduce an "all IOs" function that returns all the top-level IOs as a record or record-act-alike object. Side note: this may be of interest to `MultiIoModule` users?
- Have the top-level BlackBox IO be dummy object that emits connects and stuff at its immediate children level, instead of being an actual object in the hardware graph. Unclear if this can work without requiring changes to user BlackBox code, since the IO `Bundle` would no longer be a `Bundle`.
- Something else?

No file or test is named; start by tracing the BlackBox and ExtModule behavior implicated by issues #249 and #282, especially how top-level IOs and their children are emitted to FIRRTL. The work is done when a chosen design preserves top-level BlackBox IO operations and properties without invalid or missing FIRRTL representation, with regressions covering the reported cases.

Written by the indexing model from the issue text.