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. 
Most of the logging frameworks are pretty straightforward and similar. I've used SLF4J and Logback before, but one of the problems of SLF4J is the number of JARs required In a server-based system it's no big deal, but it's a much bigger deal on a small-memory footprint like the RoboRIO. Note that the RoboRIO has only 512MB of nonvolatile memory. BTW, all of the logging APIs are pretty similar, too.

Here are some options:

Logger | API | # of logging JARs
-------|-------|------
JDK | JUL | 0
Log4J | Log4J | 1
SLF4J + Log4J | SLF4J | 3
SLF4J + Logback | SLF4J | 2

This is going to be interesting because of the limited nonvolatile memory. We may have to see how much space is available after all software is installed and use this to influence where/how the logs are stored. Generally, it'd be better to store the log locally: we want to avoid at all costs the processor waiting for I/O, and that may mean we should not write the log to the network. (Remember that log calls will be synchronous; using asynchronous logging is rarely beneficial because you risk losing messages in critical failure situations.)

My guess it that using JDK logging to a local file will be fast and robust, is the simplest, requires the least amount of memory and JAR overhead. We can have a developer utility that connects to the robot and grabs the log file (and maybe the metrics data file if we have one, though I still think the best way to go for metrics is to use the NetworkTables and avoid a file on the RoboRIO altogether - this would allow us to have a real-time metrics monitoring application).