ENH: Migrate IVP off the legacy scipy.integrate.ode API

Problem

quantecon/_ivp.py defines class IVP(integrate.ode) — inheriting SciPy's old-generation integrator. scipy.integrate.ode has been the "old API" since solve_ivp arrived (SciPy 1.0, 2017): frozen feature-wise, documented as legacy, and a standing candidate for eventual deprecation. Because IVP is-a ode, our public surface (set_integrator('dopri5'), set_initial_value, …) is SciPy's, so upstream changes land directly on users. It is also the reason _ivp.py still carries the repo's last Py2-style super(IVP, self).__init__ call.

Proposed change

Rebuild IVP on scipy.integrate.solve_ivp (composition, not inheritance):

1. Map current methods — solve → solve_ivp with dense_output=True; interpolate → the returned OdeSolution, replacing manual B-spline plumbing; keep compute_residual on top.
2. Preserve the constructor signature IVP(f, jac=None); translate old integrator names ('dopri5'→'RK45', 'lsoda'→'LSODA', …) with a deprecation shim for one release if set_integrator is kept at all.
3. Numerical parity tests against current outputs on the doc examples (tolerance-level, not bitwise — steppers differ).

Coordinate with #111 (refactor of IVP's simulation methods) — same file, natural sequencing: this issue modernizes the foundation, #111 the surface.

Acceptance criteria

• No inheritance from scipy.integrate.ode; suite and docs examples pass
• Documented old-option → new-option mapping in the changelog

From the July 2026 technical-debt audit (AI-assisted; claims verified against 28d4b3b on 2026-07-25).

Start with quantecon/_ivp.py and the existing IVP usage in the documentation examples. Review the current methods and coordinate sequencing with #111 before comparing solve and interpolation behavior against the proposed solve_ivp approach. Done means the suite and documentation examples pass, inheritance from scipy.integrate.ode is gone, and the old-option to new-option mapping is documented in the changelog.