Additive schedule registration for TypeScript for file-splitting

[JasonAtClockwork]

Closes: #4571 - The secondary issue specifically

Description of Changes

• New spacetime.schedule(table, reducerOrProcedure) API avoids forcing tables to import reducers
  • Fixes split table/reducer files creating circular TypeScript references with table({ scheduled })
• Kept the existing table({ scheduled }) path working
• Moved ScheduleAt column tracking onto table metadata
  • Lets the new schedule API resolve schedule-at columns without relying on legacy table options
  • Reuses the same schedule resolution path for legacy and new schedules

Other Options Considered

• Rust-inspired schedule token/name handle
  • Closest conceptual match to Rust: table stores a schedule descriptor/name and the reducer binds the implementation separately
  • Avoids importing reducers from table definitions and could preserve type checking if the token carries the row type
  • Adds more API surface and abstraction, and needs careful design to avoid users managing fragile names manually
• scheduled: 'reducerName' string/name in table(...)
  • Very simple and closest to the raw module-def storage model
  • Fully breaks the runtime import cycle
  • Loses compile-time signature checking unless paired with another checker/registration API, and typos become runtime/module validation errors
  • This basically is what we had before 2.0

API and ABI breaking changes

• Adds new TypeScript API: spacetime.schedule(table, reducerOrProcedure)
• No intended breaking changes to existing table({ scheduled }) behavior

Expected complexity level and risk

3 - Preserving legacy scheduled table behavior while changing how schedule metadata is assembled

Testing

• Added new tests to cover the legacy schedule and new registration
• Ran a local throwaway test project to test before and after for both legacy + new api

[cloutiertyler]

NIT: as is usually a TypeSystem code smell. Not 100% of the time, but 95% of the time there's something better we could do here.

[JasonAtClockwork]

Fixed with 64af21f

[cloutiertyler]

By convention we should always call the value returned from schema: spacetimedb.

[cloutiertyler]

For context, the solution that @coolreader18 and I discussed was to allow you to specify on the reducer, the table you wanted to schedule to. The one detail is that we would need to enforce (at least for now), that at most (and perhaps exactly) one reducer was subscribed to a schedule table. The reason being is that the calling order would not be well defined, and we didn't want people to rely on whatever order we end up calling them in. So that would look like this:

const scheduledMessages = table({public: true}, {
    scheduledId: t.u64().primaryKey().autoInc(),
    scheduledAt: t.scheduleAt(),
    text: t.string(),
 });
 
 const spacetimedb = schema({ scheduledMessages });
 
 spacetime.reducer({ on_schedule = spacetimedb.scheduledMessages });
 // or something similar

The idea was that it would align with the future reactive reducers envisioned in: https://github.com/clockworklabs/SpacetimeDBPrivate/pull/2862

This change would also be an additive change.

Also please add any new syntax we go with to the module-test-ts module. I'm really trying to make sure those are exhaustive.