Organize the `transform` and `schedule` folders in the lighthouse module

Nobody has claimed this yet.

The `schedule` folder has proper schedules that call transforms, including HW specific ones. But it also has general infrastructure, example `builder.py`, `func.py` and `debug.py`. The `transform` folder has a similar divide, with schedules like `cleanup.py` but also core infra like `foreach` and `matchers.py`. The main separation between them is that files in `schedule` return an `ir.Module` that contains a schedule, while files in `transform` receive intermediate state (structured objects) and just complement the existing schedule.

While the distinction is fine, this is problematic in some ways:
* Repetition. Packing schedule calls a pass, while packing transform calls some upstream transforms. Same for vectorization.
* Shallow wrapping. Hoisting schedule calls hoisting transform that just calls an upstream transform and a cleanup. Same for tiling.
* It's hard to generalize the appending semantics on the callee side, when you can't guarantee the state which the schedule is on the caller side.

As we move to compose schedules with passes and descriptors, we don't need to _append_ transforms to a schedule this way, we can just create a new sub-schedule and append it to an existing pipeline. For that, the logic in the `schedule` folder is more than sufficient.

This issue proposes two things:
1. Move the sub-schedules in `transform` to their callers in `schedule` and use the latter in the existing examples and tools instead of composing them in existing pipelines.
2. Keep only core infrastructure in `transform` like `foreach`, `match_op`, `schedule_boilerplate`, `create_schedule`, and `create_named_sequence`.

The `transform` folder should not need a HW-specific sub-folder.

Inspect the lighthouse module's schedule and transform folders, including builder.py, func.py, debug.py, cleanup.py, foreach, matchers.py, and the named schedule helpers. Trace the existing examples and tools that compose these modules, then move sub-schedules to their schedule callers while retaining only the listed core infrastructure in transform; done means the existing compositions use sub-schedules without a hardware-specific transform subfolder.

Written by the indexing model from the issue text.