Additive schedule registration for TypeScript for file-splitting

[JasonAtClockwork]

Closes: #4571 - The secondary issue specifically

Description of Changes

• Added new onSchedule optional parameter for reducers and procedures as suggested by @cloutiertyler to move towards reactive reducers
  • Enforced at most one scheduled reducer/procedure per schedule table
• 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
  • Kept schedule.scheduleAtCol for compatibility

Other Options Considered

• Add new additive API .schedule()
  • Was the first implementation of this branch but was the wrong direction for the future
• 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 options to .reducer() and .procedure() for onSchedule
• 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
• Updated module-test-ts coverage to show both legacy and new reducer scheduling
• 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.

[JasonAtClockwork]

I've refactored the tests with 2b21a5d

[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.

[JasonAtClockwork]

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: clockworklabs/SpacetimeDBPrivate#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.

I've completely refactored the PR to move in this direction as .schedule() is definitely the wrong direction and is removed from this branch. I have supported both .reducer() and .procedure() though procedures were not called out.

I did go with onSchedule rather than on_schedule to match the rest of TypeScript but as this is a bit of a departure and you think we should go with on_schedule I'll fix that up.