Static Comms and Controller-Specific Init

[dmadison]

This PR reworks the I²C communication setup: instead of being in the namespace, the controller-specific I²C functions are now in the ExtensionController class as static functions, with protected member functions that use the data.i2c member and have the ability to modify the ExtensionData when called.

This serves two purposes:

1. Better encapsulation. The ExtensionController class is a high level wrapper for communication and data for every controller. It makes sense to include the controller-specific I²C functions as part of that interface.

   Originally I separated these out to prevent the class from becoming too "monolithic", but as they're simple and not used anywhere else in the library I think they definitely have their home here. Note that the lower level I²C functions are still a part of the NXC_Comms.h header.

2. It allows derived classes (i.e. specific controllers) to write and read arbitrary data from the controller without having direct access to the I²C object.

This second point is necessary for the major feature of this PR: controller specific initialization.

The virtual function specificInit() has been added to the end of the connect() function, returning a boolean for whether the initialization is successful. Most controllers will use the original function in ExtensionController, but some controllers such as the Drawsome tablet (#57) require extra register writes before they'll communicate properly. Using a virtual function here lets each class specify its own extra initialization while maintaining encapsulation.

To utilize this I've made the controllerTypeMatches (previously controllerIDMatches) function public so the user can easily check if the connected controller matches the one used by the derived class, and subsequently invoke specificInit(). See the MultipleTypes example for a demonstration of how this works.

Since I'm already playing with the program's communication flow, I also decided to remove the reconnect() function. This was not well documented and it wasn't clear to the user how it was any different than the plain-old connect() function (hint: the latter did not clear the control data). Why you would want to keep the control data if you're trying to reconnect to a controller whose data has presumably updated in the meantime, I don't know. It seemed prudent to make the distinction at the time, but having two nearly-identical functions with no explanation as to why seems more confusing than anything else. So now the reconnect() function has been removed, all examples have been updated, and the connect() function will clear out the connected controller type and control data when called.

Aaaand since I'm now changing the examples, I added a 1 second delay during reconnect attempts, both to prevent spamming the "disconnected" notice and to wait for the user to plug the controller back in (or fix that loose breadboard wire).

Last but not least, the namespace-scoped identifyController() function has been refactored to decodeIdentity(), so as not to be confused with the class-scoped identifyController() function that polls the controller for its identity bytes and returns the enumerated controller type. The extras folder documentation has also been updated accordingly.