The SpikeDisplayNode object isn't working properly. Queueing of spikes there appeared to be what was causing the problem.

I need to consider an alternative way of handling the SpikeObjects. In the past I've used a circular buffer but that has
problems with having a set size. I can use an stl::queue but queues are not thread safe, which is something that we
definitely need.

Anyway the plots show up and dance when the viewer is turned on.  I still need to implement a Stereotrode plot and then the
tetrode plot. I'll probably derive them from the ElectrodePlot base class instead of creating a base classs from which all
three plot types are derived from.

Finally I need to get a better handle on the setup of the OpenGLCanvas and how its sized.  How the "Magical" scroll bars work
and how to auto place the plots.

Do we force all the plots to be of the same type? Or do we mix in Electrode Plots with Tetrode Plots?  If so how do we orient them all?

initial checkin of the SpikePlotting directory. This will contain all of the objects used  for drawing individual spikep plots

Initial commit of the files needed for the SpikeDisplay. I created an SpikeObject file as well. This is how spikes will be represented in the SpikeDisplayNode and used by the SpikeViewer

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.

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.

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

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.