Add order=2 Hessian preparation via value_gradient_and_hessian!!

[yebai]

Extends prepare(adtype, problem, x; order=2) to build Hessian machinery for scalar-valued problems on the DI and Mooncake extensions, returning (value, gradient, hessian) from a new value_gradient_and_hessian!! generic. Unifies the per-extension caches (DICache, MooncakeCache) so one struct carries every derivative order, with explicit cross-arity error messages replacing prior MethodErrors. DI uses the in-place DI.value_gradient_and_hessian! with caller-owned buffers; Mooncake uses its native prepare_hessian_cache API.

Hessian is needed by some variational inference algorithms. See TuringLang/AdvancedVI.jl#255

[github-actions]

AbstractPPL.jl documentation for PR #163 is available at:
https://TuringLang.github.io/AbstractPPL.jl/previews/PR163/

[codecov]

Codecov Report

❌ Patch coverage is 95.62044% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.69%. Comparing base (1599516) to head (d70a945).

Files with missing lines	Patch %	Lines
ext/AbstractPPLTestExt.jl	89.65%	3 Missing ⚠️
src/evaluators/Evaluators.jl	84.61%	2 Missing ⚠️
ext/AbstractPPLDifferentiationInterfaceExt.jl	98.24%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #163      +/-   ##
==========================================
+ Coverage   88.14%   88.69%   +0.54%     
==========================================
  Files          15       15              
  Lines         886      982      +96     
==========================================
+ Hits          781      871      +90     
- Misses        105      111       +6     

☔ 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.

[shravanngoswamii]

Just one small suggestion.

Can we validate order before building the evaluator?

Right now order=3 still calls problem once, and the user can get an output-arity error before the actual invalid-order error. See:

julia> using AbstractPPL, ADTypes, DifferentiationInterface, ForwardDiff

julia> calls = Ref(0);

julia> f(x) = (calls[] += 1; [1 2; 3 4]);

julia> AbstractPPL.prepare(AutoForwardDiff(), f, zeros(2); order=3)
ERROR: ArgumentError: A prepared AD evaluator must return a scalar or AbstractVector; got Matrix{Int64}.
Stacktrace:
 [1] _ad_output_arity
   @ ~/Work/vectorly-ai/AbstractPPL.jl/src/evaluators/Evaluators.jl:277 [inlined]
 [2] prepare(adtype::AutoForwardDiff{…}, problem::Function, x::Vector{…}; check_dims::Bool, context::Tuple{}, order::Int64)
   @ AbstractPPLDifferentiationInterfaceExt ~/Work/vectorly-ai/AbstractPPL.jl/ext/AbstractPPLDifferentiationInterfaceExt.jl:75
 [3] top-level scope
   @ REPL[5]:1
Some type information was truncated. Use `show(err)` to see complete types.

julia> calls[]
1

julia>

I expected this to throw ArgumentError("`order` must be 1 or 2, got 3.") without calling f.

Maybe both DI and Mooncake paths can do:

order in (1, 2) || throw(ArgumentError("`order` must be 1 or 2, got $order."))

before the AbstractPPL.prepare(problem, ...) / evaluator(x).

[yebai]

Thanks for catching this! Fixed in b98f027, together with a few related improvements helpful for AdvancedHMC/AdvancedVI:

• order is a type parameter of Prepared with a public order(::Prepared) accessor, so it can be retrieved reliably without inspecting cache internals.

[shravanngoswamii]

Looks good to me! Thank you!