Constructor/factory methods collide with type-class-level methods

[rjhuijsman]

We currently have two overlapping problems:

1. If I add a constructor/factory method named ref, it'll silently collide with the MyStateType.ref() method that's already present on every state type class. We currently have nothing that prevents that, and it almost certainly surfaces as a nasty type error or runtime crash.
2. Even if we detected current naming collisions and prevented them, the fact that constructors/factories are on MyStateType prevents us from ever safely adding any new methods to that state type class.

• For example, if I wanted to add MyStateType.query(...) to the framework, I couldn't do that safely: a customer may already have declared a query constructor/factory.
• If I added query anyway, any customer with a query constructor/factory would now be permanently stuck, unable to upgrade: they can't rename/delete their factory method (Reboot doesn't support that, yet).

The conclusion from my brainstorm with @benh, even though neither of us love it: let's namespace all factory methods under MyStateType.factory, so e.g. await MyStateType.create(context) becomes await MyStateType.factory.create(context). That frees up the top-level namespace for any future additions we might want to make. We're OK with the slighly-less-nice-to-write code because it's something agents will write, and it still reads pretty clearly to a human.

We should make this change, and do a thorough pass through the skills in public/reboot/plugin and the examples in public/reboot/examples to match this new pattern.