feat: reworking test util

[harrysolovay]

Reworks our approach to spawning test chains. Before, we were spawning in the same place that we were using. This excessive spawn/kill slowed down test execution. For our testing purposes, isolated test networks don't necessarily matter. If/when this becomes a requirement, we can manage this within test_ctx as well.

To run a network-dependent command, prefix the command with usage of the test_ctx CLI.

deno task run test_ctx.ts <your command here>

The test_ctx.ts starts a server, which is responsible for opening polkadot CLI processes on-demand. It also runs your command, passing in the server's hostname and port as env vars. Configs within test_util/configs use these env vars to request their respective runtimes' dev net ports. The subprocess then uses the config as normal. Upon the subprocess's exit, the test ctx process kills all polkadot process instances.

Sounds like a mouthful, I know. So why this approach?

The main reason is to support our codegen vision #226. Developers will be able to test their code with ease.

main.ts

import { polkadotPattern } from "https://deno.land/x/some-polkadot-pattern-lib/mod.ts";

const root = polkadotPattern(/* some usage here */);

Normally, the developer would run this with something such as deno run -A main.ts

To make use of the test env and configs, they need not touch the actual code:

deno run -A https://deno.land/x/capi/test_ctx.ts \
  deno run -A main.ts --import-map=./test_config_remappings.json

---

Related changes:

• Moved the codegen CLI entrypoint to the root. Felt necessary given that we now expose a root-level test_ctx.ts CLI as well
• Test util import alias t -> T (was conflicting with t context exposed from Deno.test)

[kratico]

LGTM 🚀