Consider allowing caller-supplied buffer optimization for return values

Based on discussions in wasi-http/#8, we should consider a return-value optimization that avoids calling realloc by instead allowing the core wasm caller to supply a (buffer, length) i32 pair as a param. From my perspective, the main questions to consider are:

• For this to be useful, the optimization needs to apply not just for list/string return types but also result<string> and other nested cases. But how far should this go? In the limit, it could apply to any use of list/string that's not nested inside a list, but that's probably too far.
• If the return value is a dynamically-sized list/string which needs more bytes than given, should it just fall back to calling realloc and can the caller then be expected to observe this case by noting that the returned pointer is not the same as the given one?
• Is the speedup worth adding the special case?

Start by reading the linked wasi-http/#8 discussion and this issue's questions about list/string, result, nested return values, realloc fallback, and observable pointers. Define the optimization's scope and fallback behavior, then document or specify the decision and evaluate whether the speedup justifies the special case.