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. 
Great suggestion, @AGausmann. Using a logging framework (whether it's the built-in [Java Util Logger](http://www.vogella.com/tutorials/Logging/article.html), the far more common [Log4J](http://logging.apache.org/log4j/2.x/), the more recently popular [SLF4J](http://www.slf4j.org), or any other) is very good for recording various messages, exceptions, and for understanding the order that things happen. Yes, most production software uses logging frameworks for these purposes. So I agree using JUL is great for things like this. For one thing, there's no need for an additional logging.

But what I think @Zabot is talking about is more logging of a metrics, which probably would be more of a CSV format. Think about it as a print out of recurring numeric information, so that at any point in time we know the values of all of the important metrics. There are lots of easy ways to do this on desktop- or server-based programs, but on a robot our resources are more constrained.

One option to do this is for various components to write to the existing Network Tables framework, and to have the logging part on another computer (e.g., the dev laptops, the driver station laptop, etc.) just listen to the network tables to grab and record the values; i.e., a "remote recorder" approach. The benefit is that it places a lighter load on the RoboRIO: it doesn't have to write to files, and the Network Tables are already being written to the network. Another benefit is that a server running on one of the laptops could automatically process and graph this data, even in real time if we wanted. However, the problem is that if we don't have this separate logging service running, or it's not connected, we lose the data.

Another option is to have a thread read the Network Tables on the RoboRIO, and to append to a local file. This "local recorder" approach is more robust (the network is not involved, separate services are not required, etc.), but it requires more resources on the RoboRIO. And it requires periodically connecting and downloading the files.

Ideally we might consider both: during very early stages of development (when timing is probably not going to be that critical) we use the "local recorder" approach, but during final testing and competition when RoboRIO resources are more important we disable the local recorder and instead run the "remote recorder".