First pass at AdaFruit Motor Shield v1.*

This is my first attempt at implementing an AdaFruit motor shield with directional control.

Hoping to see if I am on the right track before I finish this up (tests, documentation, etc).  

You can create a motor the traditional way with the controller:

```javascript
new five.Motor({
  pins: { pwm: 11 },
  controller: "ADAMOTOV1"
});
```

But since these motors are called out by name and it can be hard to find the documentation which tells us which PWM pin to use for which motor, I built it into the configuration of the controller:

```javascript
new five.Motor({
  name: "M2",
  controller: "ADAMOTOV1"
});
````

Thoughts?
Cool.  So when we implement a shield, like in this case, how should we extend the Motors?  Should we allow the Motor to have a controller instance passed in when the shield instantiates the motor?  Or should the shield monkey-patch the motor?  (I am in favor of passing a controller in)

Further, if these shields are part of J5 propper, then I do think they should still be in their own modules.  Saying something like `new five.Shield("ADAMOTOV1")` should internally require the shield definition.  If `lib/definitions` is an existing convention, then it seems like `lib/definitions/shields` might be the best place to put these shield definitions?

In the end, I LOVE the idea of shield support.  I like the usability of it because it maps to the real world well.  A Board HasA Shield and a Shield HasA ShiftRegister/Motors.  I should be able to inspect shields on the board: `board.shields[0]`, and I should be able to control motors on the shield `shield.M1.fwd()`.  

In the end, we don't have the cross-cutting concerns that exist today in the `Motor` class.  I really dislike how my existing implementation has the `Motor` class knowing about shift registers and specific pins of a very specific shield.  The same is true of the 2.0 board.  Splitting these things up into "Shield" definitions feels very right.