Produce assertion suggestions about missing aggregate "apply" logic.

This change is about suggesting to the user that they confirm that a given message type is properly handled in an implementation of dogma.AggregateRoot.ApplyEvent().

On more than one occasion @koden-km has encountered legitimate bugs due to missing code paths in this method.

Some of the ways such bugs manifest themselves include:

1. Events with missing or incorrect data - This happens when a value from the aggregate's state is in some produced event, but the value had never been set in the first place.
2. Unexpected events being produced - This happens when an event is conditionally produced based on some state within the aggregate root, but that state has not been set.
3. Expected events not being produced - As above with inverted logic.

This branch has been retained as an example of broken tests that fail due to such an issue.

The logic for deciding when to suggest that a user check their ApplyEvent() logic could be as follows:

• one of the assertion failures describe above has occurred
• events of that type are expected to come from an aggregate
• that aggregate type has been engaged during the test
• any call to ApplyEvent() for that aggregate did not actually alter the aggregate state

This may require additional new features allowing the user to configure how aggregate roots are compared.

Start with the issue's conditions for suggesting missing ApplyEvent() logic and inspect the retained broken example at customer/customer.go on the linked branch. Trace how assertion failures, expected event types, aggregate engagement, and ApplyEvent() state changes can be observed. Done means the testkit provides appropriate suggestions for these cases, with any required aggregate-root comparison configuration covered.