Refactor: ClientConfigBuilder-specific BuilderConfig object for configuration handling

[pileks]

This is a continuation of #1465. Huge props to @Niraj-Kamdar for doing the bulk of the work around this.

This PR introduces the concept of BuilderConfig, which is a ClientConfigBuilder-specific configuration object wherein the individual configuration sections take the shape of a Record<string, SectionType>.

This allows us to configure the client in a very readable fashion.
Let's take config.envs as an example.
Before, we used to write:

const envs = [
  {
    uri: Uri.from("wrap://ens/hello-world.polywrap.eth"),
    env: {
      foo: "bar",
    },
  },
  {
    uri: Uri.from("ens/ethereum.polywrap.eth"),
    env: {
      connection: {
        node: "https://mainnet.infura.io/v3/some_api_key",
        networkNameOrChainId: "mainnet",
      },
    },
  },
];

const config = new ClientConfigBuilder()
  .addDefaults()
  .addEnvs(envs)
  .build();

const client = new PolywrapClient(config);

Now we can write a much more succint form of the configuration:

const envs = {
      "ens/ethereum.polywrap.eth": {
        connection: {
          networkNameOrChainId: "mainnet",
          node: "https://mainnet.infura.io/v3/some_api_key",
        },
      },
      "ens/hello-world.polywrap.eth": { foo: "bar" },
    };

const config = new ClientConfigBuilder()
  .addDefaults()
  .addEnvs(envs)
  .build();

const client = new PolywrapClient(config);

This can also be seen as precursor work to #1283 as it lays the foundation of the "ideal" layout of our final config objects.

Thank you @krisbitney for the note that this PR does a few more things than the description initially explained, these are:

• replace Uri | string with Uri
• remove tracing from core
• fix http server infra build

[nerfZael]

Most of this looks great.
I left two comments.
Additionally, I find the Generic** types really awkward

[pileks]

Most of this looks great. I left two comments. Additionally, I find the Generic** types really awkward

We will delete those in a future PR:
#1506

[cbrzn]

looking solid 👏 - i share the sentiment of Jure of having the two types but I think it's fine to fix this in another PR so we don't get things bigger.

The only idea I would give is that, since we want to fix the TUri generic not going in through the entire client, we maybe have this generic only in the builder, and this takes care of sanitizing the URIs, the client would only expect an URI and wont know about any generics. Making the core types just expect Uri instead of TUri

Just one minor thing to change (an unused dependency) and we're good to go

[Niraj-Kamdar]

If tracing is only implemented in PolywrapClient, how does that affect the usefullness of the tracing? If it's no longer effective, should we discuss removing tracing altogether?

It will still be beneficial to trace subinvocation traces, tryResolverUri, loadWrapper, or any other top-level functions.

[cbrzn]

If tracing is only implemented in PolywrapClient, how does that affect the usefullness of the tracing? If it's no longer effective, should we discuss removing tracing altogether?

It will still be beneficial to trace subinvocation traces, tryResolverUri, loadWrapper, or any other top-level functions.

tbh i feel we're not really using the tracing - i think discussing to improve/remove it is worth it

[Niraj-Kamdar]

Why do we need this?

[pileks]

I'll assume that this would render the URI as a string within interpolated strings, but that's as far as I can fathom this.

TBH I've only now seen this and it's something that's been in the Uri class before, it's just been moved from lines 104-115 to here.

[Niraj-Kamdar]

Yeah I noticed that but not sure we need this functions in the first place

[Niraj-Kamdar]

LGTM! Let's get this merged and then cleanup legacy

I've completed the requested changes, github is just being weird :)