Split `PolywrapProject` into `WasmProject` and `InterfaceProject`

[pileks]

From @dOrgJelli’s comments on PR #1356:

• There are 2 major architectural changes I think are needed to better support interfaces:
  1. We should split PolywrapProject into WasmProject & InterfaceProject.
  2. We should decouple the concept of generating the wrap.info from the Compiler, and use it for the build and codegen commands (see the comment in codegen.ts that says // HACK: ....

The logic for build should be something like this:

const project = createProject(manifest);
const supportedProject =
  project.isWasm() ||
  project.isPlugin() ||
  project.isInterface();

if (!supportedProject) {
  throw Error("Unsupported project type...");
}

// 1. Parse schema & build wrap.info
const schemaComposer = new SchemaComposer(...);
const infoCompiler = new WrapInfoCompiler(...);
infoCompiler.compile();

// 2, Compile wrap.wasm
if (project.isWasm()) {
  const wasmCompiler = new WrapWasmCompiler(...);
  wasmCompiler.compile();
}

And we can refine the semantics around the polywrap build and polywrap codegen commands. Basically, we shouldn't run codegen automatically when you run polywrap build, and we shouldn't generated the wrap.info file when you run polywrap codegen.

• Plugin devs will need to run polywrap codegen for types & polywrap build for wrap.info the file.
• Wasm devs will need to run polywrap codegen for types & polywrap build for wrap.info & wrap.wasm files.
• Interface devs will need to run polywrap build for wrap.info file.
• App devs will need to run polywrap codegen for types.

^^^ I guess this is the 3rd major architectural change :P

Originally posted by @dOrgJelli in https://github.com/polywrap/toolchain/issues/1356#issuecomment-1289566074

Related sub-tasks:

• [x] #1365 For the polywrap build and polywrap codegen semantics
• [ ] more to come…

[pileks]

Currently blocked and waiting on resolution of #1365

[pileks]

The remaining work here is to create an actual split between WasmProject and InterfaceProject inside the codebase. We can safely proceed with 0.10 without this change, as it's an internal refactor and provides no QOL to the end-users as it is right now.