Toolchain: Don't Resolve Plugin ABIs at Dev-Time( Codegen & Build)

[dOrgJelli]

Describe the bug
Currently, if you are building a wrapper, and you import an interface that is apart of the default-set of plugins (ex: ens/wraps.eth:http@1.1.0), the plugin within the client is used when fetching the ABI. This is not desired behavior, see example below:

#import { Response } into Http from "ens/wraps.eth:http@1.1.0"

You would expect the above to fetch the Http abi from ens/wraps.eth when you runs commands like polywrap codegen and polywrap build, but it doesn't.

Instead, we have a plugin that is registered within the default config @ this URI. See here: https://github.com/polywrap/toolchain/blob/4eb890ef72a15dd8fc70a5d9acc91323478b651c/packages/js/client-config-builder/src/bundles/default.ts#L86-L91

So calls to client.resolve(...) will be short-circuited before reaching ENS, and will just return the manifest of the plugin. This is not desired.

Please provide the steps to reproduce and if possible a minimal demo of the problem.

1. Create a wasm wrapper or plugin project.
2. Import the interface of a default plugin (ex: ens/wraps.eth:http@1.1.0) in your schema (ex: #import { Response } into Http from "...")
3. Run codegen polywrap codegen
4. Look at codegen, types will have duplicate namespaces (ex: Http_Http_Response).

Expected behavior
Generated types should have a single namespace (ex: Http_Response).

[dOrgJelli]

Original issue: #1376

[dOrgJelli]

Closing this issue, as I now disagree with the problem / solution it is presenting. Instead we should simply allow "embedded" or "local" ABIs imports via URIs.