Adding service definitions for Projections

[jakhog]

This service definition (with messages) uses the same reverse call protocol that we use for Event Handlers and Filters.

The current suggestion is meant to support:

1. Registering a projection by:
   • ID
   • Initial state (JSON string) that is used when a projection is first created (first event occurs for a key)
   • Selected events, by event type and key selector. Currently we support keys from:
     • EventSourceId
     • PartitionId
     • A named property on the event content
2. Calculating new projection state as events occur. The key will be deduced by the Runtime, and along with the event the Runtime will send to the head the current (or initial) state for the projection with that key. The Head can then reply with either:
   • A REPLACE result, which overwrites the current state of the projection instance with the value provided
   • A DELETE result which deletes the projection instance. A new event with the same key would re-create the projection instance from initial state.

The suggestion is somewhat generic in terms of key selector and next state types, so we can if we want to allow more flexible or complex ways without breaking the Contracts in the future.

[woksin]

It seems like this should do the job.

One thing though, not really related to this, the mapping from key selector to to read model should be 1:1 IMO, we should not allow 1:* (?)

[woksin]

Can we release this as a prerelease? Would make it easier to work with, and we have the workflow for doing so :)

[woksin]

@jakhog I changed the base of this PR so merging this will do a prerelease of 5.3.0-projections.

The releasing of javascript packages is disabled though. I'm having trouble even building them locally.

[woksin]

This looks guud