Unify ODE solution types: DAESolution, RODESolution as ODESolution aliases

[ChrisRackauckas-Claude]

Summary

• Expands ODESolution to carry the union of all fields from the previously separate types: du (derivatives, from DAESolution), W (noise process, from RODESolution), and seed (random seed, from RODESolution)
• DAESolution and RODESolution are now const aliases for ODESolution, eliminating redundant struct definitions
• All build_solution dispatches create ODESolution directly, with problem-type dispatch determining which fields are populated
• calculate_solution_errors! is unified into a single implementation that branches on problem type (AbstractDAEProblem, AbstractRODEProblem/AbstractSDDEProblem, AbstractDDEProblem, or standard ODE)
• Removes ~290 lines of duplicated code across dae_solutions.jl and rode_solutions.jl (duplicate getproperty, solution_new_retcode, solution_new_tslocation, solution_slice, ConstructionBase methods, callable methods, etc.)
• isdenseplot now checks sol.prob type instead of sol isa AbstractRODESolution

Breaking changes

• ODESolution struct has new fields (du, W, seed) which changes its type parameters
• Code dispatching on the concrete types DAESolution or RODESolution will now match any ODESolution (since they are aliases)
• Code dispatching on AbstractDAESolution or AbstractRODESolution with concrete solution values will no longer match (since the concrete type is always ODESolution <: AbstractODESolution)
• The abstract types AbstractDAESolution, AbstractDDESolution, AbstractRODESolution are unchanged and remain in the hierarchy for interface purposes

Test plan

• All SciMLBase unit tests pass
• Downstream solver packages (OrdinaryDiffEq, StochasticDiffEq, DASKR, Sundials) need testing for compatibility

🤖 Generated with Claude Code

[ChrisRackauckas]

RFC @oscardssmith @TorkelE @isaacsas should we do this with the major v7 coming up? It would improve the autodiff code a lot.

[oscardssmith]

Is the improvement just that there would be less duplication?

[ChrisRackauckas]

yes

[isaacsas]

Seems reasonable to me, but I don't use DAESolution or RODESolution, so don't have a great idea of how disruptive this would be.