The AudioComponent now closes the audio device when it's not in use,
saving CPU cycles. Previously, background CPU levels would be between
8 and 10%. Now, when acquisition is not active (and audio device settings
are not being actively edited), background CPU levels drop to 2%. More
optimization will be necessary to get it down to zero, but 2% is still
a big improvement over what we had previously.

UIComponent, ProcessorGraph, etc. were still referencing the configuration
class (but not using it). Those references have now been removed, as the
configuration object will be replaced by a set of parameter and channel
objects.

If continuous channels are toggled for recording within their respective editors,
a "writeContinuousBuffer" function will be activated within the RecordNode. This
function doesn't do anything yet, but it will make it easy to add diskwriting
capabilities in the near future. Once a stable format for events has been established,
a similar function will be implemented for writing event buffers to disk.

Problem:
- There's not yet a way to get the parameters for each channel
after it's clicked

The control panel now holds an "AudioEditor" to adjust volume
and open a window to alter device settings. Audio output is definitely
working, but different buffer sizes make it sound really weird. The
same problem is present in the Juce demo app, however, so I don't
think it's a problem inherent in the GUI.

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

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.

GenericEditors now check their "selected" status before asking to be deleted.

The FilterViewport pauses for 50 ms after deleting a processor in order to
avoid double-deletions.

In combination with an EventNode, a WiFiOutput node is able to send a
simple message to a hard-coded address via UDP. This is the first sink that
actually emits an output. It's obviously over-simplified, but as a
proof-of-concept, it seems to be working well.

Generic Editors colors now match the type of processor.
The FilterViewport layout has been changed to a simple outline.

DataThreads (e.g. IntanThread, FileReaderThread, FPGAThread) are now created at
the same time as the source node, rather than at the start of data acquisition.
New methods for starting/stopping individual threads are required, although
only the appropriate methods for the IntanThread have been written.

Another important change is that the SourceNode now periodically checks for
an appropriate input source every few seconds while acquisition is not in
progress. It's the responsibility of the individual DataThreads to notify
the SourceNode if their input has disappears. In the case of the IntanThread,
this involves attempting to change the baud rate. If an error code returns,
it informs the SourceNode that the input is missing. This, in turn, informs
the FilterViewport that the source is no longer enabled, thus deactivating
that particular signal chain.