Introduce Stateful Command Handlers

[smcvb]

Feature Description

A generic form of stateful message handler is beneficial for any message handler in the system. Having this would help to construct models that contain no framework- or library-specific code.

In this issue, we'll look at the stateful command handler. A stateful command handler would, for example, be a way to deal differently with your Command Model than the current aggregate approach. Note that this is different from regular "Command Handling Components," as instead of having the handlers invoke the services to load a model, the model would automatically be injected in the handler.

Hence, a stateful command handler mitigates the situation where the aggregate Repository should be wired and invoked.

This could also be used to have an alternative to the current Saga implementation. Instead of the saga class being the state, process, and handlers in one, we would have (a) separate event handler(s) receiving the transaction state and performing the process.

This idea obviously begs the question of how we will automatically load the state (aka, the model) for these handlers. For aggregates, this is straightforward, given the model identifier is typically identified in the message (so, the @TargetAggregateIdentifier).

Current Behaviour

You could regard the Aggregate and Saga support as a form of stateful message handler, although it is rather a "model message handler" approach.

Wanted Behaviour

An automated way to make concise message handling classes that receive a command and some state to act on.

Notes

Note that issue #2399 might be a solution towards having stateful message handlers. So, be sure to check that ticket when working on this issue.

[smcvb]

Although the focus was around stateful command handlers, they do provide the basis for other stateful message handlers in the future. Pull requests that went into this effort are #3296, #2399, #3314, providing the logic around the StateManager as one of the more important components to inject any form of entity users might need. Once pull request #3355 is merged, the corner stone to configure all this through the new configuration API will also be in place.

With all that, I feel confident we can close this issue. Although the original scope was wider, dedicated tickets like #3357 and #3358, combined with all the previously mentioned efforts, allow us to close this issue soon.

[smcvb]

Closing this issue as resolved as the final part of this issue was merged in through pull request #3355. If curious on the full implementation of this feature, note that pull requests #3296 and #3314 played an equally large role in this.

Lastly, the generic "stateful message handling component" desire this ticket originally referred to has been replaced for message-specific tickets. For the event and query issues, we refer to this and this issue respectively.