But they won't do anything useful until the ProcessorGraph is updated

The EditorViewport now contains buttons to scroll through multiple tabs,
or scroll across long signal chains. Now, there can be infinitely
many signal chains of infinite length (if you have a lot of time
on your hands).

Functions for managing the signal chain are no longer handled by
the EditorViewport, but by the SignalChainManager

Three important changes:
- The FilterList is now the ProcessorList
- The FilterViewport is now the EditorViewport
- Any classes that need to access important UI objects have become subclasses
  of the "AccessClass". Such objects automatically obtain pointers from
  the UIComponent and register the MessageCenter as an ActionListener. This
  will make it much easier to allocate pointers to objects.

The DataThread shouldn't have a MML all the time, but it does need it
when signaling that the data source is not found.

Also fixed a line in the FilterViewport that was causing the enabled
status of editors to fail to update.

The reason between the UI interactions with the DataThread was simple: it
was using a type of lock that's meant for interacting with the UI.

This seemed to fix all the issues with dropped samples, but we'll still
have to run it through more rigorous tests in the future.

Processors used to have their sample rate and inputs/outputs set when
their source/dest nodes were set. Now, this step doesn't occur until
after the signal chains are constructed. So far, this seems to make
things run much more smoothly.

It was a float vs. int problem!

The LfpDisplayNode/LfpDisplayCanvas are more stable now, although there's
still a bug in the DisplayNode causing small gaps to appear in the buffer.

Because the WiFiOutputEditor also had timerCallback() defined, it wasn't able to
fade in upon creation. This method was modified to solve the problem.

To simplify text alignment, the InfoLabel now uses an FTSimpleLayout object
to automatically wrap text within the bounds of the OpenGLCanvas. This will
allow a welcome message and simple instructions to be displayed.

Since every processor now gets asked to enable() prior to the start of
acquisition, it's much simpler to move the steps involved in preparing
for acquisition into these methods. This the processor from beginning
acquisition when prepareToPlay() is called upon initialization.

When an LfpDisplayCanvas was hidden for more than a few seconds, it would lose
track of the displayBufferIndex, causing it to pause for a few seconds when
it comes back into view. Now, the DataViewport sends a "refresh" reminder
to the canvas, to remind it to update its buffer indices in order to
display new data.