Jump problem violates immutable problem assumption

The integrators seem to inherit shared mutable state from the jump problem. This seems to violate the assumption that "Problem-related types in DifferentialEquations.jl are immutable." (https://docs.sciml.ai/DiffEqDocs/latest/basics/problem/). Here is a MWE of the issue:

using JumpProcesses

rate1(u,p,t) = p.λ
rate2(u,p,t) = p.λ
affect1!(integrator) = (integrator.u[1] += 1)
affect2!(integrator) = (integrator.u[1] += 2)
crj1 = ConstantRateJump(rate1, affect1!)
crj2 = ConstantRateJump(rate2, affect2!)

u₀ = [0]
p = (λ = 2.0, )
tspan = (0.0, 10.0)

dprob = DiscreteProblem(u₀, tspan, p)
jprob = JumpProblem(dprob, Direct(), crj1, crj2)

# Integrators inherit shared mutable state from the jump problem.
integrator1 = init(jprob, SSAStepper())
integrator2 = init(jprob, SSAStepper())
integrator1.cb.condition === integrator2.cb.condition

# This causes the solve of one integrator to affect the other.
solve!(integrator1)
println(integrator1.cb.condition.prev_jump)
# prints 1
solve!(integrator2)
println(integrator2.cb.condition.prev_jump)
# prints 2 (depending on random luck)
println(integrator1.cb.condition.prev_jump)
# also prints 2

Presumably this would lead to issues if one were to e.g. manually do multithreaded parallelism over many solve's with the same problem, which in my understanding should be a valid thing to do, even if an EnsembleProblem is preferred?

There's already #184, which looks related, but from the discussion there it didn't seem like this issue was a precise dup.

Start by running the MWE and tracing init(jprob, SSAStepper()) through the JumpProblem integrator and callback condition setup. Done means separately initialized integrators no longer share mutable callback state, so solving one does not change the other's prev_jump value.