Use public APIs for AutoDePSpecialize wrappers

[ChrisRackauckas-Claude]

Ignore this PR until it has been reviewed by @ChrisRackauckas.

Summary

• construct the AutoDePSpecialize opaque callable through the public RespecializeParams.OpaqueVoid API and reuse the existing dual-aware wrapfun_iip path
• derive FunctionWrappersWrappers' concrete single-cache storage type through its public cache-mode API, then use its public typed constructor
• replace private SciMLBase checks with problem_type/StandardNonlinearProblem and SymbolicIndexingInterface.all_symbols
• add a direct ForwardDiff dual-call regression test and bump NonlinearSolveBase to 2.39.1

This removes the ExplicitImports QA violations without making internal helper names public. The FunctionWrappersWrappers compatibility floor is raised to 1.9.3, where the required public constructor is available.

Closes #1118.
Supersedes #1073.

Validation

With current compatible dependency versions on Julia 1.12:

• NonlinearSolveBase QA: 20 passed
• NonlinearSolveBase Core: passed, including AutoDePSpecialize opaque-p (25 passed)

With the new compatibility floors pinned (FunctionWrappersWrappers 1.9.3, SciMLBase 3.37.0, SymbolicIndexingInterface 0.3.43):

• NonlinearSolveBase QA: 20 passed
• NonlinearSolveBase Core: passed, including AutoDePSpecialize opaque-p (25 passed)

Commands:

NONLINEARSOLVE_TEST_GROUP=QA julia +1.12 --project=. -e 'using Pkg; Pkg.test()'
NONLINEARSOLVE_TEST_GROUP=Core julia +1.12 --project=. -e 'using Pkg; Pkg.test()'

Whole-repository Runic 1.7.0 and git diff --check both completed with exit code 0.

The root NonlinearSolve Core group was also run. It reached the pre-existing continuation allocation assertions, where sweep_per_step(prob_big) measured 92.64 bytes against <48 and arclength_per_step(prob_big) measured 48.0 against <48. The sweep result reproduced unchanged on clean upstream/master; this PR does not alter those continuation drivers or their test thresholds.

[ChrisRackauckas-Claude]

Implementation and validation log:

• based on clean upstream/master at 2b0dda5f64402c5177507d9b1bb2e73ed0db4e5b
• commit: 2c44a60252b751740871a1dba96692ae66e95119
• verified the public constructor path against both FunctionWrappersWrappers 1.10.1 and the new 1.9.3 floor
• ran official NonlinearSolveBase QA and Core groups with current dependencies and exact compatibility floors; all four runs completed successfully
• ran whole-repository Runic 1.7.0 and git diff --check; exit code 0
• root Core exposed an unrelated allocation-threshold failure that reproduces on clean master; no assertion was skipped, disabled, or loosened

[ChrisRackauckas-Claude]

Superseded by #1124, which takes the route @ChrisRackauckas asked for: rather than reconstructing these objects through indirect public surface, promote each name at its owning package and then use it directly.

Two findings from a local QA run on clean master that change the picture here:

1. RespecializeParams.wrap_void_opaque is already exported and documented in the released RespecializeParams 1.x, and ExplicitImports never flagged it. The rewrite of that path in this PR was not required.

2. Clean master has four non-public accesses, not two — ExplicitImports reports only the first failing module, so NonlinearSolveBaseForwardDiffExt's violations were masking SciMLBase.ImmutableNonlinearProblem and SciMLBase.has_sys in src/autospecialize.jl.

Also worth recording: the problem_type(prob) isa StandardNonlinearProblem substitution in this PR is not equivalent to the guard it replaces. IntervalNonlinearProblem also defaults to problem_type = StandardNonlinearProblem() and is also <: AbstractNonlinearProblem, so it would newly pass the guard and then reach prob.u0, a field it does not have.

Closing in favor of #1124.