Dedicated display controller so that CPU cycles are not stolen from audio / sequencer

[bwhitman]

One of Tulip's strengths but also its achilles heel is the "GPU" - we use a single ESP32S3 to run Python, AMY, handle USB, touchscreen, MIDI, I2C and crucially a 30FPS 1024x600 display that is fed by GDMA from SPIRAM. That last thing eats almost an entire core of Tulip while running complex things, and worse, eats SPIRAM bandwidth. You'll see this be a problem when you switch Tulip apps while playing audio or a sequencer -- they will stutter. You can work around this by not doing complicated display stuff or switching apps, but we want those features too.

Some ideas to fix this include:

• Use a new espressif chip that has a dedicated controller: ESP32-P4 is an obvious next step and ships with a MIPI display controller that can run 24 bit color at 30FPS at 1024x600. This chip is not yet publicly available, but devkits are. Micropython is not yet ported (we're working on it!) and the devkit still reiles on a C6 to do wifi/bluetooth.
• Use the Pi Pico 2/ RP2530 and its HSTX display peripheral. This chip is available but not yet in packages that have PSRAM nor wifi, and we still need a few months for devs to build scaffolding for large display code
• Use a 2nd esp32s3 just for display. We can use 16 pins for RGB565 and use both cores to handle display code. We can send display instructions over serial or SPI from the other chip, which can run AMY and Micropython. This is the simplest option, as the esp32s3 is widely available and cheap and we already know everything we need to know about it.
• Use a 2nd esp32s3 or RP2530 just for AMY, as in AMYchip. Keep the display running on the esp32s3 that micropython shares.