PixelBuf: TM1814 needs to dynamically modify the header bytes to set brightness

[jepler]

TM1814 LED strips use an overall strip brightness value that is transmitted as the first 64 bits of data.

To allow the brightness to be dynamically updated, these 8 bytes of the header need to be modifiable.

However, the "transmit buffer" is a read-only object and is only intended to be available inside the _transmit method, so there appears to be no way to update the header (or, for that matter, trailer) values.

Possible approaches:

1. A new pair of methods "update_{header,trailer}" accept a buffer of equal length to the original header/trailer and update in place
2. A pair of new properties header and trailer are added, which are writable buffers
3. A new property buffer is added, which is a writable buffer
4. (the above but as methods)
5. A new constructor variant accepts a writable buffer object (this style of constructor would be incompatible with the one that takes header/trailer); the caller would construct a larger buffer with room for the header & trailer and pass in a sliced memoryview of it to the PixelBuf

For now, the brightness of TM1824 strips will just not be settable after construction time.

[jepler]

@tannewt I have a vague recollection that you had a good and strong motivation for NOT letting the caller pass in the buffer, and preferred to add header/trailer arguments instead. Is my memory right? Can you reconstruct your position on this?

[tannewt]

@jepler I think it was to save memory by not allocating the post-brightness buffer until a non-1.0 brightness was set.

I think an option 6 where transmit is given a bytearray instead of a bytes object may be best. That way the transmit function can mutate it (to set brightness) before transmitting it. The buffer still stays "internal" then too. The subclass will want to override the brightness property so that the internal post-brightness buffer is never allocated.