Remove named multi-return from function types (for now at least)

[lukewagner]

Currently function types are slightly asymmetric with results having an extra single-unnamed-result option. As #356 points out, we could make params and results fully symmetric by saying that both could either be a list of all-named- or all-unnamed types. I think that topic requires some more discussion to motivate and understand the implications for bindings generators in various languages.

In the meantime, though, I don't think anyone uses or even knows about named multi-return -- the much more common thing to do is to return a tuple or record (almost always wrapped in a result). I think this means we can expect to see
an ad hoc mix of multi-return and tuple/record in practice which seems like needless inconsistency (and wasted time arguing over what if any convention there should be). It also seems like this path will be either unimplemented or untested in current bindings generators, which bodes poorly if anyone ever does decide to use this feature.

Thus, this PR proposes that, at least until we decide to go for full symmetry, we lean into the asymmetry (which is already present) and disable this additional case of named multi-return that (afaik) noone is using. If however anyone is using and appreciating named multi-return, I'd be very interested to hear about it! (I'll leave this PR open for a while to collect feedback.)

[Mossaka]

This will simplify the specification a lot. Thanks

[lukewagner]

Ok, since noone seems to be using multi-return afaics and this is a conservative change we can always relax later (via #356), I'll go ahead and merge now (which may shake out more use cases, which will be useful data).

[alexcrichton]

This change is going to be shipped with Wasmtime 24, to be released August 20, as part of the update in bytecodealliance/wasmtime#8965