I'm okay with the binaries being GPLv3. Let's just say that they are.

Using a $(shell) substitution causes the command to be run immediately,
which is not going to work the first time you run this rule since the
file being ldd'd won't exist yet.

I'm a horrible person.

While we *could* recover this information from the map of applications,
tracking it separately makes advanceBy somewhat cheaper, since it
doesn't have to flatten two maps every time.

It is not built by default, and only works on pcap logs

I have no idea how this ever worked: Connected and Disconnected were
signalled back-to-front, so the first you'd ever see of a unique name on
the bus would be Disconnected, and the last would be Connected.

Previously, 'edgemostApp' threw in the coordinates for the next column as
well as for all the active columns, citing a poorly-specified rendering
glitch on the system bus logs. This turned out to specifically be that
one end of all signal lines was wildly misplaced. This in turn was due
to the per-bus sign stuff in 'signal' being upside-down: that function
was adding/removing one column width to compensate for the extra column
width added by edgemostApp (!), but in the wrong direction… so if we
just knocked both out we're grand.

In turn, the signs in getLeftMargin and getRightMargin (which add a
little padding so that the horizontal rules extend to roughly half a
column width past the outermost vertical line) were upside-down to
compensate for the extra column width being added.

This reduces appending of long chains of single-element lists.

This seems to be a good-enough balance between the UI being responsive
and not redrawing for every single message.

We don't need to carry this around any more, really.

Outstanding issues:

• There are no timestamps;
• You can't interact with it while it's logging; it just scrolls past
  wildly;
• I'm sure it's really inefficient.

This rejustifies the two subdiagrams appropriately so that they have the
same origin: the main reason why just catting the various lists together
doesn't cut it.

We don't show them in real time just yet, though… but this gives us an
accurate count of how many there will be once we do actually load the
file.

Yuck.

This is kind of a regression because we get all the internal guff too,
so the counter in the UI is wrong. But the loader needs all the
messages, even the internal ones, to track name changes.

We'll later update the recorder not to count messages that don't show
any output, and not to feed them to the renderer.

In the process, replace a bare tuple with a data type of our very own,
and sprinkle it with some bang patterns for fun.

Baby steps…

This makes it possible to construct a RendererState without any
messages.