Allow linking against wasmtime's minimal build

[effulgentsia]

Wasmtime releases include precompiled "full" and "min" binaries. I'd like to create a Go application that uses the min binary. My main obstacle to this is that the Go source files call C functions that don't exist in the min binary, causing compilation to fail during linking.

This PR splits those Go functions out into separate files that are gated behind build tags.

[alexcrichton]

Thanks for the PR! This is something that I'm not personally very well versed in with the Go ecosystem, however, so I'm a bit hesitant about this. Some concerns I have are:

• There's no testing in CI for this, so this is something that I believe could easily regress over time.
• Right now all the features here are "negative features" where something is asserted to not exist. Personally I've had a bad time in other contexts/build systems when things are framed this way and I find everything is much more composable when things are framed in a "positive way", or asserting that a feature does exist. Is this behavior here idiomatic in Go? Are there alternatives of how to include optional features?
• How are users expected to use this? Will *-min binaries need to be checked into the releases?

[effulgentsia]

Will *-min binaries need to be checked into the releases?

I opened #273 for just that part.

There's no testing in CI for this

I think we'll need the v43 release of wasmtime to come out first, since the gc_support setter is needed to be able to exercise the minimal build. But I can add the test coverage to this PR after that's out.

Right now all the features here are "negative features"

What do you think if we keep the .go files split as in the current PR, but instead of gating them on the corresponding feature, we just gate them on a single wasmtime-minimal build tag? It would still be a negation (as in //go:build !wasmtime-minimal), but at least it wouldn't be a negation of something that starts with no_. Go build tags always default to false unless explicitly set, so negation constraints are common, and in this case I'm assuming we want to preserve the full build as the default case when no build tag is passed.

I originally thought per-feature tags would be nice in case anyone wants to use a custom compiled wasmtime binary that's somewhere in between minimal and full, but if someone is doing that, they already would need a more complex build script and can use other techniques than Go build tags to control it: for example, their build script could just delete the unwanted .go files from the vendor directory.

[effulgentsia]

This PR is now not mergeable. I'd like to do some cleanup on it first, but it now has test coverage.

[effulgentsia]

I'm done with the cleanup I wanted to do, but (in order for the test to work) this PR duplicates changes from #271 and #273. I can rebase this if/when those get merged separately.