Use immutable `bytes` for bitmaps

[ace-dent]

Following a discussion on Discord: It seems using bytes() (immutable) rather than bytearray() may save RAM, as the data is accessed directly from flash (details). It would make sense if bitmap data used this.

1. Apparently blit() methods supports this; code should be verified.
2. Sprites do not support this (viper type issue?).
3. Check impact on bitmaps loaded from file.bin; are we loading into another bytearray/ can we save any RAM here?
4. Change bitmap builder tool (Web IDE), to output bytes.
5. Additionally, @ace-dent is happy to retrospectively do any changes to the arcade library if an API change is required.

Before starting this work, we must confirm RAM is saved at execution time. CC @fuglaro.

[masonova1]

Earlier, I said that it was a kludge to keep viper happy, but I now realize there is a behavior-based motivation for this: we may want sprites to be mutable, so that people can do per-sprite texture changes at runtime. If RAM usage concerns become critical due to this design, we can discuss a new streamedSprite or immutableSprite object to accommodate the use case, but myself and the other engineers at TC believe this to be significantly distinct from current Sprite behavior, and we think that it probably needs a different name.

[masonova1]

More or less directly continuing the Discord conversation --

If one has a singular tileset/spritesheet that never changes, ROM reads are a better fit, but immutability can get in the way when people want to do anything more complex than typical masking operations on, say, a bunch of fairly small sprites.

A driving principle of the API is one of minimizing user astonishment. If we added this functionality in the same elif train as the rest of the sprite initialization, the mutability of the sprite would be a non-intuitive function of the __init__ parameters, which would surprise me from a design standpoint, even if it was documented. This could be solved by flipping a coin to simply choose either mutable or immutable sprites, but we've painted ourselves into a corner by already assuming mutability of the Sprite in legacy. To me, it seems most preferable to implement both, and keep their differences rather explicit.

[ace-dent]

Note from @fuglaro on Discord, to test any RAM saving for Sprites created from a binary .bin file (loaded as bytes vs bytearray):

Yeah, and I think the memory saving scenarios are pretty nuanced. I think that one needs verification. I actually think that situation won't save any memory... Reason being: Literally coded bytes already exist in the python bytecode created by interpreting the python files, and since they aren't mutable, they don't need to be duplicated into new memory, so can be referenced from the python bytecode directly. That's not the case in the scenerio you point out