[HAL] Fix inline execution models (initializer inlining and dispatch ABI) (#24827)

The inline execution models were broken end-to-end in both the compiler
and runtime.

On the compiler side, the `HAL_Loader` and `HAL_Inline` dialects did not
support inlining, preventing `CombineInitializers` pass from combining
initializers containing their ops. This broke `inline-dynamic`
compilation generally, and stateful programs using mutable globals under
both `inline-dynamic` and `inline-static`.

On the runtime side, the `hal_loader` dispatch shim incorrectly
accounted for padding in the fixed portion of the VM cconv arguments by
using the C struct size, causing `inline-dynamic` dispatches to fail
with an argument/result signature mismatch.

The runtime also leaked the inline HAL storage buffer wrapper on
release. VM buffer destruction also assumed that every buffer was
created by `iree_vm_buffer_create/clone` as a single aligned allocation
containing both the `iree_vm_buffer_t` handle and its data. Inline HAL
instead embeds the handle inside a wrapper struct that maps an
`iree_hal_buffer_t`, initializing it in place with
`iree_vm_buffer_initialize`. Such buffers must invoke the wrapper’s
custom allocator to release the underlying HAL buffer and free the
wrapper, rather than calling `iree_allocator_free_aligned` on the
embedded handle. Since nothing else in the handle distinguishes the two
cases at destroy time, create/clone now tag their buffers with
`IREE_VM_BUFFER_ACCESS_COALLOCATED` (set internally), and destroy takes
the free-aligned path only for tagged buffers; all others pass the
handle to their allocator.

This PR adds the required inliner interfaces, fixes the dispatch
argument handling, distinguishes co-allocated and in-place-initialized
VM buffers during destruction, and adds compiler/runtime coverage for
the affected execution models and buffer lifetimes.

Assisted-by: Claude Code

---------

Signed-off-by: Pooja Hemashekar <hemashekar@roofline.ai>