Palette: accept tuples of RGB values

[jepler]

This makes Palette more similar to pixelbuf, and lets e.g., the unmodified "wheel" function be used to set pixel values.

Testing performed: I adapted an existing demo (pygamer) of mine to directly use wheel() tuples instead of converting them to 24-bit integers, and it worked.

[kattni]

Thank you for adding this! @jepler If you'd like another test, please provide me with a test build for CLUE and I will do so.

[kattni]

Tested successfully on CLUE with display_text. Thanks for adding this!

[kattni]

Passed! 🌮 Thanks for adding this! Tested on CLUE.

[dhalbert]

Could you test that the pinyin and german builds actually work? Try a simple I2C example or something. I found that setting inline limit below 35 or so can produce broken code.

[tannewt]

I'm ok merging this in but I want to note why I didn't support tuples. I only supported ints because it's easy to provide a conversion library in Python and having only one type of input keeps the code slimmest. Ints are a better single thing to support because tuples cause at least one more allocation.

[jepler]

I will give I2C a test on an M4 board with the specific optimization flags that we put on pewpew m4. I'll do the proposed merge of color value parsing (of pixelbuf and displayio palette) under a separate PR so that the clue lib doesn't have to wait on this.

[dhalbert]

BTW, I just suggested I2C because the underlying ASF4 code uses a lot of potentially inlined stuff. There's nothing special about I2C per se.

[dhalbert]

OK, I am going to close this and open a new PR for two reasons:

1. Making space in pewpew_m4 via different means (turning off analogio for now).
2. Seeing if I can easily generalize passing a color sequence to more than a tuple. neopixel et al take a sequence, which could be a tuple, a list, or any kind of iterator (e.g. range(3) works).