CHV / True Jump method implementation discussion

I've started working on an implementation of Romain's true jump method / CHV method, but some issues have cropped up. @ChrisRackauckas any thoughts about the following:

There is a design decision for how to handle constant rate type jumps. We can either

1. Treat them via CHV (i.e. in the generated ODEs).
2. Treat them via an existing aggregator, but then have to add a continuous time callback to rootfind where the physical time (which is now an ODE variable) equals the next jump time.

I am leaning towards the former, but we then give up all the optimizations we have for selecting the next jump via the different constant rate aggregators.

Another issue is I'm not sure how to handle the user interface. Since the method uses a rescaled "simulation" time, s, it seems like we need to return some kind of custom solution object to users so they can get the solution / index the solution at physical times, t(s) (t(s) is itself solved for in the ODE). Likewise, we need to intercept calls to solve to add continuous callbacks for hitting physical stopping times and such. Wrapping the user provided f(du,u,p,t) function to take t(s) is no problem, but the input/output boundaries seem more challenging.

The issue names no files or tests. Start by reviewing the proposed CHV/True Jump implementation discussion, focusing on constant-rate jump handling and the rescaled simulation time s. Done requires settled behavior for physical-time solution indexing, stopping-time callbacks, and the choice between aggregators and generated ODEs.