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.
> Perhaps I am missing something, but a rule like this can be extremely limiting. It makes refactoring code difficult while maintaining unit-level coverage

Sorry, but I didn't expect to have any push back on this one, because there is nothing about the way an analog Accelerometer is initialized—as far as user code is concerned—that will change. If it does, then we've done something wrong.

>  If the component no longer depends on the IO layer, then it doesn't feel right to continue to mock out the IO layer and require a specific controller implementation

We need separate tests the initialize every device type or controller for for every class. Don't change the existing tests, because nothing about that API and its semantics should be changing here. 

> but keeping the tests as-is would change the nature of the tests from a unit test to an integration test. 

I'm not sure I agree or disagree with this, but I also don't want to argue about it either. We need separate tests for each device type and controller that each class implements.