Add DifferentiationInterface.Prep support to anyeltypedual

[ChrisRackauckas-Claude]

Summary

This PR adds support for DifferentiationInterface.Prep types to opt out of dual number checking in the anyeltypedual function. This fixes issue SciML/NonlinearSolve.jl#718 where Prep objects in parameters were incorrectly triggering automatic differentiation detection.

Problem

When users pass DifferentiationInterface.Prep objects as part of their parameter tuple to NonlinearSolve, the current anyeltypedual implementation was detecting these as dual-number-like types and incorrectly promoting the state variables to ForwardDiff.Dual types, even when no AD of the solve process was intended.

Solution

Following the same pattern as ForwardDiff.AbstractConfig (lines 353-361 in SciMLBaseForwardDiffExt.jl), this PR:

1. Adds DifferentiationInterface to the [weakdeps] section of Project.toml
2. Adds the corresponding extension to [extensions]
3. Creates a new extension file SciMLBaseDifferentiationInterfaceExt.jl with anyeltypedual overloads for Prep types that return Any, effectively opting them out of dual checking

Changes

• Added DifferentiationInterface to weakdeps and extensions in Project.toml
• Added compat entry for DifferentiationInterface versions 0.6 and 0.7
• Created new extension SciMLBaseDifferentiationInterfaceExt.jl with anyeltypedual overloads for Prep types

Testing

• ✅ All existing SciMLBase tests pass
• ✅ Tested with the MWE from the issue - now correctly uses Vector{Float64} instead of Vector{ForwardDiff.Dual{...}}
• ✅ Code formatted with JuliaFormatter using SciMLStyle

Related Issues

Fixes SciML/NonlinearSolve.jl#718

🤖 Generated with Claude Code

[gdalle]

@ChrisRackauckas the Prep type is internal to DI. If you rely on it, please open an issue on the DI repo so that I make it public in the next release

[ChrisRackauckas]

We basically need to say that if you have some cache object create by prepare_x inside of the parameters, this does not mean we are differentiating the solve by the parameters. Is that the right abstract type to hit?

[gdalle]

Yup