feat(*)!: Uses wasm-pkg-client for loading dependencies

[thomastaylor312]

This is a fairly large PR because this dependency is used everywhere. cargo component now uses the new wasm-pkg-tools toolchain to load deps, which means that both OCI and Warg are supported. This tries to stay as close to the original code style as possible, but I did have to make large changes to how dependencies were being resolved to account for the
new library. There are a couple major breaking changes to be aware of and one question to answer. This PR is already quite large, so I figured it would be better to probably merge this and then deal with follow ups to any of the outstanding questions below:

• Bindings are now generated every time. Where the actual dependency is being loaded from is now abstracted away by the client, so we can't check if those files have changed on disk. I personally don't think this is the worst thing, but if people really want that functionality, we can add support for that into the package tools.
• Offline deps currently does not work, but that is something that will be added into wasm-pkg-client instead of doing checks within cargo component itself.
• Currently the registries specified within Cargo.toml are not used in favor of using the config file for wasm-pkg-tools. I am not sure if we wanted to use that to override the wasm-pkg-tools config or just drop it entirely. I would like to address this one before merge.
• Until wasm-pkg-client has support for publishing, I have left support in to use warg directly. Once we have that added to wasm-pkg-tools, we can change the behavior here

[thomastaylor312]

Just a heads up that I know the tests for wit aren't passing yet because I forgot to update them, but I wanted to get this out there so we could start discussion on it

[thomastaylor312]

Marking this as ready for review. After talking to @calvinrp, we're going to merge this once we have the next version of cargo-component cut so we can start making changes. We will keep the git reference to wasm-pkg-client until we're ready to release it and cargo component. As for registries, we're ok with removing it for now as it can be specified with the wasm-pkg config. The only exception to setting a registry locally is likely to be for private registry overrides and is likely to be better done with a local wasm-pkg-tools config file. We'll be following up with support in wasm-pkg-client for offline support and publishing

[calvinrp]

@thomastaylor312 Reviewed as best I can. Likely going to be issues that we can fix after merging, as well as things that we will want to revise further. I think we should cut a release for wasm-pkg-client and then update the dependency here (instead of pointing to a git rev).

But I'm OK with proceeding and fixing issues after merging.

[jsturtevant]

I tried this out and was able build a wasi-http component using this config in the cargo.toml:

[package.metadata.component.target]
package = "wasi:http"
version = "0.2.0"
world = "proxy" 

I saw it downloaded the wasm layer from $HOME/.cache/cargo-component/cache/sha256\:5a568e6e2d60c1ce51220e1833cdd5b88db9f615720edc762a9b4a6f36b383bd which aligns with the package at https://github.com/orgs/bytecodealliance/packages/container/package/wasm-pkg%2Fwasi%2Fhttp

[calvinrp]

This is part of a big refactor to leverage wasm-pkg-tools to support both OCI and Warg registry protocols. Expect that main branch needs to be a bit of staging ground while follow on PRs land. So we will hold on doing the next cargo-component release until these changes are sorted.

This PR is intentionally pinned to a git rev, but will be updated in future PRs.