Make MaterialData dynamically resizeable

[JessyDL]

Currently the MaterialData binding's backing storage is "set once, change never". This can work for toy examples but is bad for actual production.

Proposed changes (choose one):

1. Support growing buffers, and alert materials through callback when realloc happens.

Advantage:

• one ground truth location
• easy to access anywhere.

Cons:

• double buffering issues/complexities
• possible large amount of materials to update on realloc
• unstable
• defrag issues, though due to the presence of realloc functionality this should be trivial to resolve

2. materials/bundles are in "charge" of their own buffers.

Implementing this in bundles has the distinct advantage that materials already store their instance data there

Pros:

• stable
• extremely flexible
• safe (no chance of overwriting other's data)

Cons:

• Lots of small allocations, which we want to avoid

3. mixed approach

Implement material data handling in either bundles/material (prefer bundles), defer to a global buffer unless size exceeds N bytes, or global buffer runs out of size. When global buffer runs out of size, either allocate 2nd global buffer or do smaller self managed allocations.

Pros:

• stable, other buffers aren't affected
• flexible

Cons:

• defrag issue potential (when multiple global buffers exist, but all are underutilized. This can be alleviated with realloc