Reboot Projection API Model

[jeremydmiller]

Medium to long term things here folks, so nobody get too upset or anxious about anything here yet. I'm just thinking out loud here.

Problems:

• Code generation approach and the conventional Create() / Apply() is successful for simple workflows, but breaks down badly for any kind of remotely complicated workflow
• Some people just don't like the conventional approach period, and now that C# has pattern matching (yes F# folks, I realize that was never an issue for y'all), there's maybe less advantage in the conventional approach
• Explicit code via CustomProjection is a bit clumsy to use today. Doesn't work for live aggregations. Would help if this was an easier escape hatch from the conventional/codegen approach
• "Slicing" API is less than obvious to use. That might be more of a documentation/example issue
• Would like to do more to incorporate event/stream archiving soon, especially when the Event Store Partitioning is done
• There's no easy way in the conventional approach to say "apply this logic on the last encountered event", and that's come up quite often lately

Possible Solutions

• Consider using source generators for the conventional application of events instead of the JasperFx.CodeGeneration / JasperFx.Compiler model? Not sure if that's enough value to justify the effort, but it's also a way to dip the toes into it
• Push through issues with CustomProjection so that it can be used for live aggregations
• New "explicit aggregation projection" model where the user gets the current aggregate (or not if it's new) in a method, and returns a response object that's something like Store/Delete/UnDelete/Archive/Partials telling Marten what to do next. Vague hope here is to do something that's easy to test
• Reevaluate the whole event slicing API. Ick, ick, ick.

Independently, I'd like to move this one up into a release soon: #2533