[Stack Switching] Fix binary writing of continuation types when GC is not enabled

[kripken]

Continuation types refer to a Function type, and the old code was
emitting a top type instead of that function type, which is invalid.

[tlively]

This doesn't seem right. If GC is not enabled, so we only have reference types, then e.g. a local variable holding a reference to a particular function type should be emitted as funcref whether or not stack switching is also enabled.

How does CallIndirect emit its function type index? We should do the same when emitting a continuation type definition.

[kripken]

Ah, good point, I had a vague worry like that, but didn't see tests fail so I figured I was confused...

Fixed like callIndirect, and simplifed callIndirect too.

[tlively]

Actually, this doesn't make any sense without typed function references. If the ref.func is just a funcref, then there's no way to validate that the continuation type has the the same parameters as the type of the function reference it is initialized with.

And we don't differentiate between typed-function-references and gc as features, so continuations without GC simply don't make sense.

[kripken]

Wait, wasn't there an effort to avoid continuations from depending on GC?

Anyhow, I'm fine with making stack switching depend on GC, is that the right thing then?

[tlively]

Yes, but they still depend on typed function references, and we don't differentiate between that and GC. So making stack switching depend on GC is the right thing for our purposes. We can revisit this in the future (probably by adding a separate typed-function-references feature again) if anyone really needs it.

[kripken]

Ok, I opened #7830 and will close this.