I should be able to cause Property changes in QL

Summary: Crossing the Rubicon here: introduce a _changeProperties() function that updates the Space.

Needed for Eric's Playtesting Space.

This is a big deal, but now that we're starting to have Effects it is starting to look plausible. Some notes:

This function would return a new kind of Value, an Effect. This might be a new sort of Collection, or it might be something above that. It is more honestly Monadic than the rest of the Collections, and describes a change to be made. As with the Console, this change is probably described in terms of a function.

The -> operator will map Effects. That is, _changeProperties(My Link -> Something) -> _somethingElse() will cause _somethingElse() to be processed after the Effect resolves. However, this does not mean that the Effect happens immediately: it means that we do nested rounds of QL processing. If the chain encounters another Effect, that will effectively flatMap, and linearize the Effects.

It isn't clear what the syntax inside of _changeProperties() is -- how we specify a Property/Value pair -- but it must not involve effing _self. Really, we're looking for tuples, and we may need to invent tuple syntax for it.

Separate Phrases that include Effects are considered parallel to each other. (As opposed to Stages within a single Phrase, which are sequential.) However, when we get to the end of processing an Expression, we collect all Effects that involve sending SpaceMessages, bundle them all together, and send them as a single atomic unit, to be processed as a single operation in the SpaceCore.

In order to achieve transactional behavior, the collected SpaceMessages will be sent with the StateVersion of the State that produced them. When SpaceCore receives this, it will check that Version against the current Version of the Space, and reject the changes if they are obsolete. Later we will dealing with automatic retries: this will require refetching an updated version of the user's view of the State, which is some extra complexity. But for the short term we will need to accept (rare) rejections at the user level due to race conditions, so that we can preserve invariants properly.