feat(esp32s3): add PSRAM support

[digitalentity]

PSRAM support for ESP32-S3. Enabled via numa_psram_qspi and numa_psram_octal build tags.

• OPI PSRAM was tested on ESP32-S3-WROOM-1U-N16R8
• QSPI PSRAM not tested yet (I don't have the hardware)

Test on QSPI board with: ./build/tinygo flash -size=short -serial=uart -target=esp32s3-psram-qspi -monitor -panic=trap examples/psram

Test on OPI board with: ./build/tinygo flash -size=short -serial=uart -target=esp32s3-psram-octal -monitor -panic=trap examples/psram, should be getting something like this:

=== PSRAM Example ===
psramBuffer start address: 0x3D000000
psramBuffer size:          1048576 bytes
Writing test pattern to PSRAM...
Verifying test pattern...
SUCCESS: PSRAM 1MB read/write verification passed!

Partly fixes #3772

[digitalentity]

I am removing QSPI support for now. The boards I got also have PSRAM connected via Octo-SPI. Apparently all ESP32-S3 boards with 8M PSRAM use OctoSPI.

OctoSPI is verified on 2 different ESP32-S3 boards now.

[fleshin]

works fine with XIAO ESP32S3

[digitalentity]

@deadprogram I believe this is ready

[rdon-key]

#5567 changes how ESP32-S3 IROM/DROM are placed in flash and mapped through the MMU, in order to support larger flash images. This PR also changes the ESP32-S3 MMU and linker layout for PSRAM, and as far as I can tell it still assumes the current flash mapping (see src/runtime/runtime_esp32_psram.go).

Since both touch the same memory-layout area, @deadprogram would it make sense to settle #5567 first, and then review this one against the resulting layout? Happy to help with the rebase either way.

@digitalentity does that match your reading, or do you think the two are independent enough to review separately?

[digitalentity]

@rdon-key I suspect this PR might fix the large image boot issue as well. Could you please check? I'll look at the #5567 in the meantime.

[rdon-key]

@digitalentity

I tested #5554 with the same large-DROM reproduction case used for #5567.

It still fails in the ROM bootloader before TinyGo startup is reached:

load:0x3c000020,len:0x780104
Invalid image block, can't boot.

So #5554 does not appear to fix the large image boot issue. #5567 still seems to be needed to change how the IROM/DROM segments are laid out in the ESP image.

[digitalentity]

@rdon-key how do you test? Is it sufficient to put 1M data into the DROM to make it fail? I suspect it's merely the image layout issue. The #5567 is still needed to fix it, but I'm wondering if changes to the linker script and the image builder would be sufficient.

I'll try blending our changes together and see what happens.

[rdon-key]

@digitalentity
I used exactly the reproduction case documented in #5567: a deterministic 7.5 MiB file embedded with //go:embed into DROM, flashed to an M5Stamp-S3A.

I haven't tested the exact minimum failing size separately. It appears to be around 1 MiB. If you're testing it, I'd also try a case near the flash limit.