We'll use this type to encapsulate the notion of a per-instance memory

This is a stop-gap, since we'll be moving the execution buffer
elsewhere.

It got pulled in indirectly, but it should be used directly.

This is if you want to create a set of allocated weights
without creating the whole model

Basically instead of taking GBytes and having memory entangled with
the model weights, these are now separate concepts. So
create_model_desc also returns a GGMLLanguageModelDesc with
separate weight tree descriptions for the memory weights and
the model weights, where there will be one set of memory weights
per inference instance as opposed to per-model.

Lets not re-use the main computation context, as that needs to be
preserved in a special way.

This can be used to build the compute graph without actually
building the executing the graph, which can be useful for memory
allocation.

These are based on the newly added ggml_alloc context mode in
ggml, which use an allocator to specify graph memory layout as opposed
to the naive linear allocator. We can also use the allocator to compute
how much memory is actually required.

The general flow would be that you first run the forward pass with
worst-case inputs in "recorder" mode to compute a maximal memory usage
profile. The recorder mode sets tensor data addresses to a region
that doesn't exist in memory and also takes care to ensure that writes
to the tensor using the ggml-gobject API don't actually write anything
to memory.

Then afterwards, you can allocate a buffer of the required size, then
 use the allocator in "alloc" mode to create the same layout, this time
backed by a real buffer.

Using the alloc mode is fairly cheap, since it doesn't require
any system calls (all the memory is allocated upfront).

…mory size

With this we can finally remove the semi-hardcoded memory estimator
for GPT2 models and instead use a real estimate based on the model's
actual memory usage.