Stuck chains in ODE models

[JasonPekos]

This is a recurring problem people run into when doing Bayesian ODEs (I think this can happen in Stan too, not just Turing).

Relevant discourse thread: https://discourse.julialang.org/t/turing-nuts-chains-getting-stuck-at-the-parameter-bounds/85947.

My vague intuition for what's going on is:

1. Parameters initialize in a way where the resulting ODE is numerically unstable
2. This results in us pre-emptively rejecting the ODE (with an eval at -Inf) based on the solver retcode.
3. So there's an area of parameter space where the loglikelihood, for our purposes, is -Inf.
4. If we initialize there, we get stuck.

This might not be right — I'd want to run some tests to confirm this. Frustratingly, this makes benchmarking with @btime difficult, because benchmark performance is dominated by stuck chains.

I guess solutions would be:

1. Better initialization
2. A better way to score the loglikelihood in numerically unstable areas.

---

Example of this happening with the LK model:

[JasonPekos]

FWIW I think this can happen in Stan too, but it's super rare, so they're doing something different. If possible, we could force both Stan and Turing to initialize at the same parameter set, and then watch the differences in behaviour.