c-api: Dealing with lists is inconsistent across APIs

I wanted to write down something that irks me when working with Wasmtime's C/C++ API that I've noticed recently. It boils down to basically the handling of lists throughout the API is pretty inconsistent and varies place-to-place in terms of ownership, semantics, representation, and performance. For example:

* `wasm_module_imports` fills out `wasm_importtype_vec_t*` which the caller needs to deallocate.
* `wasm_functype_params` returns `const wasm_valtype_vec_t*` owned by the callee.
* `wasmtime_instance_export_nth` is an iterator-style API of walking over a list (as opposed to returning a list)
* `wasm_module_new` takes a byte list parameter as `const wasm_byte_vec_t*`
* `wasmtime_module_new` takes a byte list parameter as a ptr/len combo
* `wasm_func_callback_t` takes arguments as `const wasm_val_vec_t*` and fills out `wasm_val_vec_t*` as a return
* `wasmtime_func_callback_t` takes arguments/results as ptr/len combos

Much, if not most, of this is `wasm.h` idioms clashing with what's natural to implement in Wasmtime. Wasmtime internally has some inconsistencies too, however -- in https://github.com/bytecodealliance/wasmtime/pull/11937 the `wasmtime` Rust API for getting the types of a function's parameters means that the result looks quite different than other C APIs.

On one hand this is `wasm.h`-vs-not, but the way we've designed the C API right now is that it's not possible to avoid using `wasm.h` so users are forced to deal with this no matter what. That's not great, in my opinion, so I wanted to file this issue.