Allow the user to provide "describers" on a per-handler basis.

It might be useful if the user could provide a function that can describe the current state of a projection (or perhaps any other handler) so that it can be observed when a test fails and/or between each engine dispatch/tick.

I am not sure how much merit this idea has; specifically, I wouldn't want devs to spend forever writing and updating code that exports SQL database state in a human readable format. For SQL projectionkit could help with that, but obviously projections are not limited to any particular storage technology.

This is also potentially a LOT of data, possibly too much to include in an expectation report, but I suppose it could be written to disk and the expectation report could print the file location. Another option would be to reimplement some kind of verbose option.

The issue names no files, tests, or entry points. Start by tracing how handlers, projections, engine dispatch/ticks, and expectation reports are represented, then compare the proposed per-handler describer with the verbose option and output-to-disk ideas. Done requires an agreed design and documented behavior for describing handler state without imposing a storage format.