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 implemented in `PWM.getSpeed()`:

    public double getSpeed() {
        int value = getRaw();
        if (value > getMaxPositivePwm()) {
            return 1.0;
        } else if (value < getMinNegativePwm()) {
            return -1.0;
        } else if (value > getMinPositivePwm()) {
            return (double) (value - getMinPositivePwm()) / (double)getPositiveScaleFactor();
        } else if (value < getMaxNegativePwm()) {
            return (double) (value - getMaxNegativePwm()) / (double)getNegativeScaleFactor();
        } else {
            return 0.0;
        }
    }

and `getRaw()` is returning an int between 0 and 255.

Really, using something like `MINIMUM_PERCEPTIBLE_SPEED` is just being very safe without having to understand how the WPILib is implemented (which can change in 2015, remember). I'd recommend it, but it's fine if you think it's excessive.