Decide a removal schedule for the 21 deprecated base-level shims

Summary

The 21 base-level compatibility shims (quantecon/arma.py, quantecon/lqcontrol.py, and so on) each carried a header comment saying they would be removed in v0.8.0. v0.8.0 shipped on 2025-02-13; the package is now well past it. #864 changes the wording to the version-agnostic "will be removed in a future release", which stops the statement being false, but deliberately does not set a new date — that is a decision for the team.

The question

Do we want to commit to an actual removal release, or keep the shims indefinitely?

Substituting another hard-coded version (0.13.0, say) without a plan simply resets the same trap, which is why #864 avoided it.

What the shims currently do

Each is a thin __getattr__ module that forwards to the private implementation module and emits a DeprecationWarning telling the user to import from the top-level quantecon namespace instead. They are, as far as I can tell, fully functional — this is purely about how long we carry them.

The affected modules are arma, ce_util, compute_fp, discrete_rv, dle, ecdf, estspec, filter, graph_tools, gridtools, inequality, ivp, kalman, lae, lqcontrol, lqnash, lss, matrix_eqn, quadsums, rank_nullspace and robustlq.

Things worth weighing

The lectures and a large body of user code may still import via these paths, so removal is user-visible in a way the deprecation warning alone is not. Against that, the shims have now been "about to be removed" for longer than they were ever meant to exist, which erodes the signal.

There is also a dependency on #853: six objects listed in the shims' __all__ are not importable from the top-level namespace, so for those the deprecation warning's advice currently fails. Removing the shims while that is unresolved would strand those objects entirely.

Suggested outcomes

Either pick a target release and record it here and in the CHANGELOG so the wording can point at something real, or state explicitly that the shims are permanent and downgrade the warning's language accordingly. Either is fine; the current in-between state is the problem.

Review the 21 shim modules listed in the issue, #864's wording change, and #853's missing top-level exports. Check the CHANGELOG and current release policy before proposing either a concrete removal release or permanent shims. Done means the team decision is recorded here and in the CHANGELOG, with warning language consistent with it.