Change object type ID from 0-127 to 2 bytes so it can be used for versioning objects

[elcojacobs]

The current implementation of object type is a uint8 with a value of 0-127 to define the application object type. This is a small range that could be exhausted quickly. While it is unlikely that we will have more than 127 concurrent object types on the firmware, it leaves no room for deprecating objects.

If we change the implementation to use 2 bytes instead of one, we have a much bigger pool so we can do version management of objects:

• If we change the implementation of an object in a way that the previous object definition is not compatible, we can assign it a new ID. The service layer can read the old definition (which is still stored in EEPROM) and create an object of the new type with the same settings for those that are compatible.
• If we deprecate an object, we do not have to re-use the object ID for a new type, which would be dangerous.

The object creation command now uses an array of factories that is directly indexed by the object type ID. Instead of using the object ID directly as the index, we should search the array for the matching factory.

[elcojacobs]

Done and merged into feature/brewblox

Type IDs are now defined in a central place and resolved at compile time using templates and overloading: https://github.com/BrewPi/firmware/blob/feature/brewblox/app/cbox/AppResolveType.cpp

The object factory contains the typeIDs and searches the factory container instead of indexing it directly: https://github.com/BrewPi/firmware/blob/feature/brewblox/app/cbox/CboxApp.cpp#L63