Potential changes for a breaking release

It might make sense to layout some potential updates here that would make the workflow nicer and more consistent with other SciML libraries, but be breaking. JumpProcesses has a lot of historical cruft at this point which could potentially be cleaned up with a redesign. Some examples:

• Specifying VRJ aggregators.
  • We essentially have a FRM currently, what I proposed the other day is a DM. There is also Anderson’s MFRM method and others. Plus the mix of integrating via the ODE integrator vs. quadrature. But selecting solvers here would require an interface.
  • To eventually support hybrid models it might make more sense to just have some type of structure that stores / encapsulates multiple solver selections (for constant jumps, variable jumps, ODEs, SDEs, etc), and knows how to put them together into a single solver.
  • For pure jump systems that have VRJs it seems like we might benefit from a version of SSAStepper or such and avoid ODE integrators (i.e. just have a time-stepper with root finding).
• Not passing or building aggregators at problem construction (removing mutable state in JumpProblems). i.e. defering aggregator selection until calls to solve.
• Storing rngs in integrators instead of in aggregators/JumpProblems (and providing users an API to access them that we internally use too).
• Not having solve reseed when no seed is passed, but leaving such behavior to higher level callers.
• reinit support to avoid overhead of reconstructing solvers if making changes as mentioned above.
• Have aggregators store their kwargs, i.e. instead of passing dependency graphs as arguments to JumpProblem pass them as arguments to constructors of aggregators, i.e. NRM(; dep_graph), RSSA(; variables_to_jump_graph), etc.
• Nailing down the bounded VRJ interface (should we have one function that returns all bounds and a time window, a function that just does upper bounds and time window, leave alone as separate functions as we do now)?

edit: This is just a draft, but I'll try to iterate on over time.

Start by reviewing how JumpProblems, aggregators, and solve currently interact, including the NRM and RSSA constructor patterns. Compare the listed proposals with the existing solver-selection, RNG, seeding, bounded VRJ, and reinit behavior. Done requires a decided redesign and corresponding implementation scope, rather than one isolated edit.