chore: Separating codegen from our public API (shaderbits)

[!NOTE]
Draft issue

Our code directories roughly correspond to typegpu/* entry-points, as well as the tgsl directory (for code-gen functionality) and shared directory (used by everything, depends on nothing. Shared utilities).

There are currently imports to and from each directory, which sometimes causes hard to untangle circular imports. My proposal is to slowly move towards an untangled hierarchy of directories in a series of steps that we can introduce and rollout progressively, instead of a big rewrite.

The high-level goals I'd like to achieve after the whole migrations are:

1. "Shaderbits" - Separate our public API schemas (exported from typegpu/data) from the values we use internally to infer types during shader generation. The circular dependency happens here naturally, as schemas can be called on the GPU, and often handle type coersion and conversion, which in turn needs to be reference a few numeric types by name. I call these non-public type representations "Shaderbits", and their aim is to represent WGSL schemas as JS objects, without additional fluff.
2. One-way dependencies - Drawing high-boundaries between code directories looks to be possible. common should conceptually use the public API to define things users might want to reuse very often, no need for anything else to import from it internally. std needs to define functions that accept and return schema instances, no way around that. core APIs like buffers and variables accept and operator on schemas.

Start by mapping imports among the typegpu/* entry points, tgsl, shared, and the named common, std, core, and typegpu/data areas. Trace the schema and code-generation dependencies first; done would mean the proposed shaderbits separation and one-way directory dependencies are implemented without the circular imports described.