Switch all ports to auto-growing split heap

[tannewt]

This simplifies allocating outside of the VM because the VM doesn't take up all remaining memory by default.

On ESP we delegate to the IDF for allocations. For all other ports, we use TLSF to manage an outer "port" heap. The IDF uses TLSF internally and we use their fork for the other ports.

This also removes the dynamic C stack sizing. It wasn't often used and is not possible with a fixed outer heap.

Fixes #8512. Fixes #7334.

[bill88t]

This has the potential to fix a lot more issues than just these two.
For those as eager as me to test it, make fetch-port-submodules before compiling.

The first round of testing (on esp32) is however not so pleasant. MemoryErrors.
A simple way to reproduce it would be:

>>> a = bytearray(60000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError: memory allocation failed, allocating 60000 bytes
>>> import gc
>>> gc.mem_free()
4130048

Big bulky modules (even around 40kb) fail to load.

[RetiredWizard]

I tried loading the UM Tinypico artifact (hoping #7288 might be affected). Some moderately large programs that exhibited the memory variable corruption before now run fine, but the largest programs that exhibited the issue now simply don't load and immediately display the following message:

Adafruit CircuitPython 9.0.0-alpha.2-12-g151e38eefe on 2023-11-01; TinyPICO with ESP32-PICO-D4
>>> import PyDOS
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError: 

[dhalbert]

This is really wonderful. It's so much simpler and more straightforward. I added a couple of CIRCUITPY-CHANGE annotations and will just add those in myself and the approve and merge.

[dhalbert]

@bill88t @RetiredWizard

@tannewt and I discussed this. We will merge as is and then work on tuning to fix MemoryErrors.

[RetiredWizard]

I did some more testing on the Unexpected Maker TinyPico and this does seem to fix #7288. The memory error I was getting on loading my largest program also goes away if I don't include the wifi parameters in settings.toml. It's probably not surprising that enabling the web workflow stresses the available memory, but perhaps some additional garbage collecting around the web workflow could help?

Edit: Just realizing web workflow is C based, garbage collecting probably doesn't apply 🤷
I have also caused the memory error upon load without web workflow enabled by attempting to load an even larger program.

[tannewt]

Edit: Just realizing web workflow is C based, garbage collecting probably doesn't apply 🤷
I have also caused the memory error upon load without web workflow enabled by attempting to load an even larger program.

Ya, it doesn't do garbage collecting. With the split heap work, IDF allocations will be intermingled with CP heaps rather than leaving the PSRAM exclusively for CP. It won't work for ever larger programs unfortunately.