Bring back the `commit` parameter in aggregate event handlers

[rkaw92]

Previously, a commit parameter was normally included in on* aggregate methods. This has proven to be incorrect, as the commit was only being passed during aggregate rehydration, not in nominal operation (because of the difference between _applyEvent vs. _applyCommit).
For a commit parameter to make sense in both cases, a dummy Commit would have to be created on the first run (non-rehydration) and populated with the predicted sequenceSlot.
An additional note needs to be taken that the metadata may still vary between runs - the party responsible for loading the aggregate may pass extra arguments to Commit, thus enriching it.

An alternative may be to abandon the commit parameter in aggregate event handlers altogether and remove it from all test cases / examples. The aggregates would then be forced to use their internal counters (via getNextSequenceNumber() ?) at time of event application.

[rkaw92]

The Aggregate side of this issue has been handled in 0.2.0-dev/#d7e2070 by restoring the "commit" parameter in event application functions.
tryWith and/or the loader still need enhancements to supply the commit upon invoking the aggregate. Also, the relation between the passed Commit object and the one newly-generated when committing the aggregate should be determined. One of those instances may be redundant.