Generalizing the VM buffer type and adding VM buffer ops.

[benvanik]

Previously the VM had a special builtin for read-only buffers and it was always just a placeholder for something more meaningful. This is the start of that. This implementation will undergo a lot of changes as VMVX is brought up but is the first wave of work to unblock that exploration.

vm.list/iree_vm_list_t are useful for storing reference-counted objects and heterogeneous element types and supports resizing, and this new vm.buffer/iree_vm_buffer_t is useful for fast access to fixed-length sets of primitive values with the ability to bitcast the storage. The buffer is access checked (preventing writes to read-only memory), origin checked (preventing inadvertent lifetime extension), bounds checked/alignment-enforced, and is a ref object like any other so that proper lifetime is tracked across host/guest/module boundaries.

The intent is to have a memory-safe byte buffer that supports external host memory, read-only mapped buffer memory (.rodata sections), and read/write memory allocated from within the user VM code. There's a long list of ops in the HAL that needed this (such as hal.command_buffer.update_buffer) and techniques like uniform buffers or mapping memory directly from devices into VM-accessible data.

The op set here is relatively mundane with malloc, memset, memcmp, memcpy, etc and typed load/store routines. Future extensions to this can add more ways of loading/storing such as multi-value loads/stores to reduce overhead - VMVX may use that to emulate vector loads/stores, for example, with a vm.buffer.load.i16x32.

[benvanik]

(still a few tests to write, but otherwise ready for review I think)

[ScottTodd]

No real comments :P

Straightforward buffer manipulation code that fits into the rest of the VM nicely. Thanks for the header file comments and explicit access types.