Generic changes:

- Genuinely unused variables (-Wunused-variable): delete
  them. Sometimes add a comment if the variable is for an extension of
  the code that isn't done yet.

- Variables that became unused due to commented-out
  code (-Wunused-variable): comment out their definitions. Dirty, but
  that's because commenting out code instead of deleting it is
  dirty.

  Many of these are due to commented-out printlines that should have
  been log messages that only get emitted at high verbosity level.

Specific changes:

- SpikeObject.cpp (-Wunused-value): move initialization of loop
  variable into first for loop clause to silence the warning.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>

createProcessorFromDescription() purports to only want one Intan demo
board at a time, but in fact bars multiple "File Reader" or "Custom
FPGA" subProcessorType values. We're adding hooks for a socket reader
here, and the current code would limit us to just one, which isn't
what we want.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>

The IntanThread can report TTL events on its 6 input channels. This was tested
with an Arduino; input detection is fast and reliable.

The IntanThread also generates its own timestamps, allowing the software to move
toward a framework in which timestamps come from input sources, rather than
from the RecordNode.

Finally, an ArduinoOutput module was added, which allows the software to
communicate with an Arduino via serial output.

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.

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.

Started integrating the TetrodePlot class. Oddly the projection plots aren't working although they were working in the stereotrode class, I'll have to figure that one out

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?

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