Add a way to test IO in the automated testsuite

[Wallacoloo]

Currently, when you do something complicated that should eventually lead to an IoPin write, it's very difficult to tell if it actually resulted in one. There are a few possible solutions to this:

• when DO_TESTS=1, have the IoPin track its output state and provide access to it via a lastDigitalWrite() function. Downsides: not all writes go through IoPin. OutputEvents, for example, only allow access to the PrimitiveIoPin (it's near impossible to provide access to the IoPin itself, due to its non-copyable nature. Plus, the OutputEvent doesn't need the extra information that the IoPin wraps). Also, a non-generic HardwareScheduler implementation might not directly call PrimitiveIoPin::digitalWrite (e.g. the RPi DMA scheduler).
• when DO_TESTS=1, allow for installing an onOutputEventProcessed handler function into the Scheduler that gets called whenever the Scheduler relays an OutputEvent to HardwareScheduler.queue(). Downsides: This only guarantees that the event reaches the HardwareScheduler; not that it's actually processed or processed at the correct time.
• Have each PrimitiveIoPin track its own state when DO_TESTS=1. Downsides: most invasive. Extra work for EVERY platform.

Note: in general, there's not always a way to actually verify that a pin IS set, without configuring another input to be directly connected to it. This is because the pin can be set by a peripheral other than the CPU (e.g. DMA). On the Raspberry Pi though, the GPLEV register will read the value of an input OR an output.

Also, although it may only be possible to generically test IO propagation through to the point where the platform-specific HardwareScheduler takes hold of it, platform-specific testing could be employed to test that any OutputEvent reaching the HardwareScheduler is handled correctly. So, option 2 (the onOutputEventProcessed callback) is perhaps the best option.

[Wallacoloo]

In the spirit of unit testing, it may be best to NOT have something like a Servo verify that the IoPins are actually set. Rather, the servo verifies that it exposes the correct information to the State, and then the State verifies that it processes that information correctly and sends the right bits to the Scheduler, and so on (this isn't to say that IO doesn't need to be tested, just that it should only be tested by the relevant classes).