Changes required for initialization

JumpProblem has a unique set of problems to solve for initialization. Ignoring SSAStepper for a moment, JumpProblem wraps another problem and relies on the integrator of the wrapped problem. It wraps the inner prob.u0 in an ExtendedJumpArray containing extra values. This makes initialization problematic since initializeprobmap returns a Vector{Float64} which does not have the required extra values, thus leading to an error.

ExtendedJumpArray is not public API, and hence MTK cannot handle this as an edge case. One solution discussed is to wrap the inner prob.u0 in an ExtendedJumpArray when the user calls solve/init. However, this is still problematic:

• We'd need to allocate the array for the required extra values every solve call
• Each solve call would call init on the wrapped integrator twice: once just to run initialization, and a second time with NoInit to change the type of integrator.u to the appropriate ExtendedJumpArray.

Another potential solution is for JumpProcesses to take ownership of initialization - solve for the updated values, update the ExtendedJumpArray, and call init on the inner problem with NoInit. The downside here is mostly just implementation. We can avoid a NonlinearSolve dependency by making it a weakdep, in a similar approach to how OrdinaryDiffEqNonlinearSolve extends OrdinaryDiffEqCore.default_nlsolve.

Start with the JumpProblem solve/init entry points, initializeprobmap, ExtendedJumpArray, and the SSAStepper exception described in the issue. Compare the initialization flow with OrdinaryDiffEqNonlinearSolve.default_nlsolve and determine which ownership approach is appropriate; done means JumpProblem initialization succeeds without the missing extra values or duplicate initialization described here.