CompatHelper: bump compat for SciMLBase to 3, (keep existing compat)

[github-actions]

This pull request changes the compat entry for the SciMLBase package from 2 to 2, 3.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

[github-actions]

Turing.jl documentation for PR #2802 is available at:
https://TuringLang.github.io/Turing.jl/previews/PR2802/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.23%. Comparing base (89b1ce0) to head (1095bfd).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2802   +/-   ##
=======================================
  Coverage   85.23%   85.23%           
=======================================
  Files          22       22           
  Lines        1483     1483           
=======================================
  Hits         1264     1264           
  Misses        219      219           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[penelopeysm]

Note that the successful CI run was with SciMLBase@2

[penelopeysm]

This PR cannot be merged: Optimization is not yet compatible with SciMLBase@3

Edit: see SciML/Optimization.jl#1179 for upstream progress

[ChrisRackauckas-Claude]

Courtesy note from the SciMLBase v3 ecosystem sweep: this PR is low-risk from the v3 breaking-surface perspective. A grep of src/ and test/ for the main v3 flags came up clean — no u_modified! call sites, no DEProblem type references, no 3-arg ensemble prob_func, no single-int timeseries sol[i] indexing. Turing's SciMLBase usage appears limited to the OptimizationSolution type in src/optimisation/Optimisation.jl, which is unaffected by v3.

One ecosystem-wide caveat: Pkg.resolve() fails on any env containing SciMLBase 3.1 right now because OrdinaryDiffEq still pins RecursiveArrayTools ≤ 3.54 while SciMLBase 3.1 requires RAT v4. Expect CI here to fail at the Pkg.add step until upstream OrdinaryDiffEq releases a RAT-v4-compatible version; re-running afterward should go green.

For reference, the SciML-side pattern PR with full breaking-change context is SciML/DiffEqCallbacks.jl#300.

cc @ChrisRackauckas

[penelopeysm]

Actually there's no reason why we need to directly version SciMLBase in Turing, we only use it to import OptimizationSolution, which we can just import from Optimization. That may lead to a transitive compat bound, but that's not something we need to worry about in our Project.toml.

[penelopeysm]

Actually plot twist but OptimizationSolution isn't even public / exported

[ChrisRackauckas]

That is a mistake on our end, we'll correct that.

[penelopeysm]

ref. SciML/Optimization.jl#1187