[thread-spawn] Allow more function types to be spawned

[abrown]

As discussed here, limiting which function types can be spawned is... well, limiting. Previously, only allowing a single i32 parameter meant that toolchains would have to create a closure, likely in shared memory, in order to pass more information to the spawned thread. This would make sense when the implementation uses pthread_create, e.g., but could be limiting in other cases.

Though that discussion never pinpointed any specific languages where this might be a problem, the limit was a bit artificial. I propose we start with a proposal that is as general as possible and whittle down from there. This change allows the spawned function to take any Wasm parameters with the understanding that this moves the complexity from the toolchain to the engine (at least when using pthreads).

We still retain the limitation that the spawned function must not return a value because there is no place to return it to: (a) the thread may start executing long after control flow has progressed from the spawn point and (b) it doesn't seem advisable to me yet to add promises/futures/etc.

[abrown]

cc: @rossberg, I think the right spec notation is likely p_1^n or something like that but hopefully p* is close enough for now.

[rossberg]

I'd probably write v*, since that's the meta variables for values, but it doesn't really matter at this level. (Otherwise it's fine, you don't need any index or superscript, unless there are multiple variables or you care about the length of the sequence.)