Add support for growing the memory block sizes

[nical]

Fixes #235.

This PR extends the AllocationsSizes configuration to define ranges of block sizes. The allocators start by allocating blocks with the minimum size and each new allocation for the same memory type doubles the block size.

This allows applications to scale memory usage more organically based on demand. While it is typically not an optimal choice for most games, it allows other types of apps that don't have well defined memory budgets to strike a good tradeoff. My own motivation comes from Firefox's WebGPU implementation. See #235 for more details.

While writing this I found out that the vulkan allocator was not taking the allocation_size parameter from its descritptor, so I fixed that along the way.

I, m not sure about how to expose this in the API. In its current state, this PR only adds to the current API and does not change anything for folks who want to stick with the current behavior (fixed block sizes).

Example:

const MB: u64 = 1024 * 1024;
// This configuration uses fixed memory block sizes.
let fixed = AllocationSizes::new(256 * MB, 64 * MB);
// This configuration starts with 8MB memory blocks
// and grows the block size of a given memory type each
// time a new allocation is needed, up to a limit of
// 256MB for device memory and 64MB for host memory.
let growing = AllocationSizes::new(8 * MB, 8 * MB)
    .with_max_device_memblock_size(256 * MB)
    .with_max_host_memblock_size(64 * MB);

But it looks a bit quirky. One might prefer to simply spell out the ranges when creating AllocationSizes. let me know what you prefer.

[Jasper-Bekkers]

@nical Please sign the commits so they can be merged.

[nical]

There you go!

[MarijnS95]

Sorry for the late review, I missed this while not being able to work on Rust projects for a while. Code looks good, thanks! Just found a few typos and broken field references. Would you be able to provide a follow-up or should I?

[MarijnS95]

Hmm I wonder if is_host is the correct moniker for something that's HOST_VISIBLE but could just as well have DEVICE_LOCAL. That's the original logic though, but then this struct was always default()ed before it seems.

Same in Metal, we probably need to start representing UMA better.