When allocate_display_bus_or_raise was factored out, the assignment
of the bus's Python type was lost. Restore it.
This would have affected displays of any type other than RGBMatrix, when
they were created dynamically. Boards with displays configured in flash
were unaffected.
Closes: #2792
This gets all the purely internal references. Some uses of
protomatter/Protomatter/PROTOMATTER remain, as they are references
to symbols in the Protomatter C library itself.
I originally believed that there would be a wrapper library around it,
like with _pixelbuf; but this proves not to be the case, as there's
too little for the library to do.
Surely readline() "rtype" is string not int as stated (and not bytes as some might expect).
Also it is not totally unambiguous what happens on a timeout so it would help to clarify in docs that on a timeout
it does NOT return with what it has read so far, rather it leaves all that in the buffer ready for a future read and returns nothing.
Likewise clarify that if timeout=0 but there is no newline it DOES return what it has read so far (NOT None).
At least this is what I think it does and/or is supposed to do!
Python docs are generally not too explicit about what is the proper treatment, so perhaps all the more reason to
clarify the interpretation adopted?
They're not readily distinguishable by type.
I also added the requested height optional parameter; this is checked
against the computed one. It's not feasible to use this parameter to
artificailly reduce the number of used rows, because changes in the
underlying C protomatter library would be required.
Finally, I added a better error message when the number of RGB pins was
not what was expected.
