Extend or rework the measurement API to express measurements directly.

[sageserpent-open]

Currently, the measurement API expresses a measurement as a mutative operation, so it can be related to a prior event if such an event exists.

While this works, it doesn't really capture the notion of a genuine measurement. As an example, we might have several events that record the gradual addition of a mass of substance to some container, or transfers of money to an account, followed by a measurement that the mass of the container is 200 Kilogrammes, or 500 Pounds Sterling in credit. The measurement doesn't relate to any of the prior events, other than stating that the prior event history in toto does not quite match what has been measured, and that the measured value should take precedence over what might have been calculated via the prior event history.

The existing API sidesteps this by tying a mutate measurement to the most recent matching event in th prior event history - this effectively slides the measurement back in time to anchor to the relevant event, which is great on the one hand as it makes queries in the past pick up better information from subsequent measurements, but means that measurements on derived properties that may depend on several events can't be expressed.

The question than arises: if the notion of measurements on a derived property is introduced, how should it interact with the existing ones? Do we drop the current notion, or perhaps look to correlate genuine measurements on property queries with mutative operations if possible, falling back to the new approach if no matching mutative operation can be found?

Also, what do we do with object invariants if a measurement would cause a derived property to contradict the state from events to the point where an invariant breaks?