Additional API interfaces and implementations


	
This should get us up to speed on most of the API stuff, in this PR we've got interfaces and implementations for: 
* Motors 
* Gyroscopes 
* Distance Sensors 
 
The only thing missing from last years robot is the accelerometer 
 
It also adds the `LimitedMotor` composite class and JUnit test cases, which though similar in concept to `SolenoidWithPostion`, isn't worth trying to abstract. 
 
Aside from that I fixed some documentation and refactored Hardware so that similar factory methods are in nested classes. 
 
Some things that might be worth considering: 
* The `Hardware` and `Mock` prefixes are a little overkill, the names are different enough to prevent conflicts, and if not, they're in separate packages. 
* If we are going to rely on the accelerometer and gyroscope more heavily then last year, it might be beneficial to have some helper classes that allow us to attach units and direction to a value, e.g. `Angle`, `Velocity`, `Displacement`, etc. 
It's better to use a local variable here, because strictly speaking it is possible (theoretically) the first call to `getSpeed()` on line 51 might return a slightly negative value while the next call on line 53 might return a different but slightly positive speed, and then the method incorrectly returns STOPPED. Now, perhaps in reality that can never happen, but a simple refactoring can eliminate this possibility:

    double speed = getSpeed();
    if ( speed > 0.0 ) return Direction.FORWARD;
    if ( speed < 0.0 ) return Direction.REVERSE;
    return Direction.STOPPED;

BTW, I think the 3 lines (with no line feeds) is much more readable, and that's why I (and many other developers) prefer to not require a newline after every `if` and `else` expression.

Oh, and I wonder if we should use something other than `0.0` for the comparison literal. What happens if the value is very small, like 0.000002? Do we want to consider that to be "moving" or "stopped"? Remember, these values are being decoded from integer fixed-byte values, so there may be a loss in precision before we see it. If we used something like 0.0001, then maybe our logic better handles those decoding errors (if they even exist). And if we did this, we probably should make it a constant:

    private static final double MINIMUM_PERCEPTIBLE_SPEED = 0.0001;

Thoughts?