Rework memory allocator in order to increase contract size

[athei]

Currently, the memory allocator lives in the client. It is pretty simple. For this reason we need to be very conservative how much memory we can use. This means that contract sizes and call stack depths are limited.

We should move the allocator into the runtime. This allows us to use a more sophisticated allocator.

cc @koute AFAIK you have an allocator in mind we should use for the runtime?

• Remove unnecessary host functions allocator usage polkadot-fellows/RFCs#4
• Choose an allocator with better worst case properties so that we can reduce MEMORY_ALLOCATOR_INEFFICENCY_DEVIDER as much as possible
• Make MEMORY_ALLOCATOR_INEFFICENCY_DEVIDER configurable since it is now depending on the runtime
• Assume a certain devider and retune our contract limits to allow for deeper stacks or more code.
• Migrate the AssetHub runtimes to the newly chosen allocator.

Alternative: Wait for the JIT

Once we move PolkaVM into the client (for the JIT) we no longer need to hold all code and memory of the current call stack in runtime memory. It will all be inside client memory and the runtime just holds a handle to it. This will likely remove the need for more memory.

My stance on this is: It will take too long to block on the JIT. We need more memory sooner to allow deeper call stacks. The linked RFC is a bit outdated (there might be new host functions it does not cover) but in good shape. It is not blocked by anything. If we get somebody to work in it, it can happen in parallel with the JIT work.

[bkchr]

This is basically: polkadot-fellows/RFCs#4

It requires to finalize the RFC, get it approved and then we can implement it.

[athei]

Agreed. I still leave this open because I can't add the other issue to my board. I also added some more follow up points that will be unlocked by the RFC.