support combining SDKs with multiple WIT worlds

[dicej]

This adds two new features:

• Multiple --world options are accepted, in which case the worlds will be
  merged into a single world for building, testing, or bindings generation.

• In addition to any worlds and/or WIT paths specified explicitly via CLI
  options, componentize-go will use go list to scan the current module and
  its dependencies, looking for files named componentize-go.toml in their
  source trees. For each such file found, any worlds and/or WIT paths
  referenced therein will be added to the respective lists. This behavior can
  be disabled using the --ignore-toml-files option if desired.

In combination, these options make it easier to use multiple SDKs or other
libraries which contain wit-bindgen-go-generated code.

Note that I've also removed the wat dependency because go build always
generates a binary Wasm file, so no need to check for or parse WAT.

Fixes #28

[asteurer]

Thanks for this Joel! I'm wondering if you might be open to having componentize-go automatically scan the go.mod dependencies for a componentize-go.toml file in the root? I have an incomplete implementation here. If I'm not mistaken, doing it this way would completely eliminate the need for passing additional arguments to componentize-go.

[dicej]

Thanks for this Joel! I'm wondering if you might be open to having componentize-go automatically scan the go.mod dependencies for a componentize-go.toml file in the root? I have an incomplete implementation here. If I'm not mistaken, doing it this way would completely eliminate the need for passing additional arguments to componentize-go.

Yeah, I was just thinking the same thing now that I've read up more on what go list can do. Are you planning to post a PR for that branch? Happy to close this one in favor of yours.

[asteurer]

I was planning on finishing that PR when I got back from Europe; however, if you have the bandwidth to incorporate the go.mod search feature into this PR, I won't be offended 😄

[dicej]

I'll give that a shot today.

[dicej]

@asteurer I just pushed an update. My version doesn't look at go.mod directly and instead uses go list -mod=readonly -m -f '{{.Dir}}' all, which lists the paths to the current module and any dependencies. The end result is pretty much the same, though. Let me know what you think.