Mass refactor the crates structure [7 / 4]

[MOZGIII]

This is a huge PR that I've built as a PoC for the more atomic crates; we can merge it as-is, or I can subdivide it into smaller parts so we can review individual changes.

Commits to review start with Split out ir parser into a separate crate: review.

The totality of the changes in this PR are:

• moving the files around
• correcting use statements

There are no semantic changes to the code, or tests; in fact, most of the files remain as-is, and don't really have any associated changes at all but the use section update and new placement.

---

This is the majority of the work required to split out the monolithic crate structure into small and atomic crates; we have resolved all of the dependency cycle issues and establish necessary patterns to move forward.

• We have crates that declare the traits either standalone or together with the related (core) types; in practice, these are waymark-<subsystem>-backend crates and waymark-<subsystem>-core crates.
• There are also two special crates: waymark-runner and waymark-runner-state; that last one could've been called waymark-runner-core, and that it because it holds the core types used by waymark-core-backend
• The backend traits are subdivided into individual crates; the backend implementations (i.e. postgres and memory) import all of those crates; subsystem driver crates (to be extracted from the runloop later) will be importing only the relevant subsystem backend: for instance, webapp doesn't need to know about the scheduler, it will only require that the backend that is passed to it implements webapp backend.
• The immediate next step to is to finally consume the benefits - and to split out leaf build targets (binaries) into their own crates; this will enable us to finally build the binaries with individual dependencies and (if needed) feature sets - enabling precise control of what code gets compiled into the final binary. This would, technically, partially address Minimize dependencies #148 by reducing the dependencies set to the minimum needed for a particular binary.

---

Again, this refactor only moves code around. It does apply no changes to the type names, or fn implementations (except correcting the item paths when they're affected by code movements).

[MOZGIII]

See #200