Imu Controller Spike

This is really just meant to be a spike to try some things out for the IMU/Accelerometer with separated controllers. I haven't extended it to Temperature or Gyro because I wanted to get some feedback first.

There is a controllers service which is responsible for mapping controllers on boards. There are two controllers implemented in this pass: AnalogAccelerometer and MPU6050. Thy both expose data.accelerometer[x,y,z] data points, but they get the data in different ways.

I tested this with an analog Accelerometer as well as with the MPU-6050.
@rwaldron said:
> I'm not thrilled about all these being in new files. There is no precedent for that and it makes me feel like we need to go and split up every other class that's profile-centric.

I struggled with this a bit.  If we have three components (accel, temp, gyro) which need share a controller, that controller needs to live some place outside of all three.  It can be argued that it can live in the IMU, but that would mean that the accel, temp, and gyro would require the IMU.  When the IMU is instantiated as a component, it needs to require the accel, temp, and gyro.  We run into a circular dependency.

My first idea was this, to create a "controllers" service which is responsible for getting and managing the controllers on the board.

After doing this, I kind of like it (I love the separation of the data retrieval from the component's logic), but I agree that there is no precedent for this.  The generic "AnalogAccelerometer" controller certainly doesn't need to be outside of the "Accelerometer.js" file.  If the consensus was that people liked it, it would likely require that everything gets affected by this architectural change.  This is mostly just a spike to see where things go (which is why I haven't done anything with temp or gyro yet).

I'm certainly open to other implementation ideas that allow for sharing of the MPU-6050 controller without requiring separate files.