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

Although it has not been rigorously tested for all cases.

Major modifications to EditorViewport::loadState() and
EditorViewport::saveState() allow complex signal chains to be loaded
and saved. There are still some issues with editor button status
on startup, but these should be easy to fix.

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.

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.

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.

Previously, if you placed a sink in front of a source, it would lead to
a never-ending "while" loop. By removing two lines (254-255), this problem
was solved.

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.