Altered the default settings of SignalGeneratorEditor and SpikeDetectorEditor to reflect the desired values for debugging the spike viewers

Channel selector buttons now can be used to toggle audio monitoring
for individual channel. One minor bug: the array of channels to monitor
is not updated when the graph is rebuilt. If new processors are added,
the mapping might be wrong.

Through the SpikeDetector Editor, it's now possible to change the channel
mapping for each electrode and adjust thresholds. It's not yet possible
to inactivate particular electrodes or change parameters over multiple
electrodes at once; these will both be necessary functions in the future.

Now, when the user clicks on a tab in the DataViewport, the corresponding Editor becomes
active. Likewise, when the user selects an Editor with a Visualizer, the corresponding
tab becomes active in the DataViewport.

Channel selection now takes place within a slick new interface. It's not
yet tied to actually changing parameters, but things should be much simpler
code-wise, as well as visually.

Added method for creating parameter editors, which can be overridden by subclasses of the GenericEditor

Slightly altered the layout of the SpikeDisplayEditor, also I changed the waveform line width from 1 to 2 pixels

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.

The waveform icons should be made a bit thicker, but otherwise these look cool.

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.