add helper methods to pack and unpack midi data bytes into number types

[soundanalogous]

examples:

packUint8 / unpackUint8
packInt8 / unpackInt8
packUint16 / unpackUint16
packInt16 / unpackInt16
packUint32 / unpackUint32
packInt32 / unpackInt32

Not sure if we need a set for 64 bits.

Also open to a naming convention here.

[soundanalogous]

pack methods could accept a number of the specified type and maybe an endian value and either return an array, or write to the stream directly (TBD).

unpack methods could accept a reference to an array and a starting index and maybe an endian value and would return the parsed value in the specified type

[dtex]

For packing, if we return to an array instead of writing directly to the stream we have the option of leveraging unused bits before writing into the stream.

[soundanalogous]

Also when unpacking, an optional length param could be used in the case that less bytes than needed for the specific type are returned.

[soundanalogous]

@zfields curious to hear your thoughts on this proposal. I assume this would belong in FirmataMarshaller.

[soundanalogous]

@finson did something similar in his Luni (arduino device driver) library, but for translating larger numbers to and from an array of bytes: https://github.com/finson/Luni/blob/b0.10-i5-globals/src/Device/ByteOrder.h. This is what initially inspired my idea to do something similar but for 7-bit midi data bytes, which is not 2 midi bytes for each 8 bit byte, it's based on the number of bits (7 per midi data byte so 3 midi data bytes to create a 16 bit integer and 5 to create a 32 bit integer, etc).

[zfields]

@soundanalogous I think they would belong as private members to FirmataMarshaller.

void FirmataMarshaller::sendAnalog(uint8_t pin, uint16_t value)

Here, you would need the ability to pack the value parameter efficiently, and having a packUint16 method sounds like a great idea.

void FirmataMarshaller::sendString(const char *string)

Here, you don't need anything extra, because basic ASCII has a range between [0, 127]. However, extended ASCII would require more sophisticated packNBytes method.

The point being, as long as the pack___ methods support the protocol they make sense. However, I would be skeptical about the need for them to have public access. Allowing a user to form Firmata compatible byte strings seems like it would be handy at first blush, but it also seems to defy the intent of FirmataClass. Adding efficiency to the FirmataMarshaller is great, but adding complexity to the public API (especially when not directly related to the protocol) seems like a mistake.

[soundanalogous]

could also consider supporting floats if necessary, however there is a huge advantage to using integers over floats whenever possible on microcontrollers without native floating point processors (most MCUs supported by Firmata). Something like a 40x more efficient using integers.