Review pin API

[hannobraun]

I've recently made improvements to the gpio and swm modules that should prevent users from trying do use pins in any way that isn't supported by the hardware. Any attempts to use pins in an invalid way should result in compile-time errors.

While I have working code that works on top of the new API, it isn't really battle-tested yet. Ideally, I'ld like to see the following:

• Use of the API by other people than me, to make sure the API is flexible enough and doesn't prevent valid use cases.
• Review by people knowledgeable about the LPC82x switch matrix, to make sure the API enforces the correct rules.

If you're inclined to help out with this, please submit your feedback to this issue. Please note that the documentation isn't really that great yet. In plan to improve that, but don't know yet when I'll get to that.

Open questions:

• Can GPIO coexist with fixed and movable functions? Section 7.4 seems to imply that GPIO input can coexist with other functions.
• Can the API be simplified without losing any capability? I'm not sure, but I have a feeling the many traits in the swm module can be reduced somewhat.

[hannobraun]

A lot of work has been done on the pin API (see #76). One of the open questions from the original comment, whether the API can be simplified, has been resolved (the answer is "yes"). The other important question, whether the hardware capabilities are correctly represented in the API, remains open.

A thought on the current API: I don't like how SWM and GPIO functionality are entangled in a single type, Pin (with impl blocks for the type in both modules). Maybe it's a good idea to use a wrapper type for GPIO that owns or borrows Pin.