Separate model-evaluation inputs from outputs

This proposes a concrete end state for #895, #1184, and #1376 after the parent-context hierarchy is removed by #1468.

Model evaluation should have a one-way data flow:

┌────────────────────────────┐
│ Model                      │
└──────────────┬─────────────┘
               │
┌──────────────▼─────────────┐
│ Context: evaluation inputs │
│                            │
│ • RNG                      │
│ • initialization strategy  │
│ • transform strategy       │
└──────────────┬─────────────┘
               │
               ▼
┌────────────────────────────┐
│ Model evaluation           │
└──────────────┬─────────────┘
               │
      ┌────────┴────────┐
      │                 │
      ▼                 ▼
┌────────────┐   ┌───────────────────────────┐
│ Return     │   │ VarInfo                   │
│ value      │   │ (i.e. OnlyAccsVarInfo)    │
└────────────┘   │                           │
                 │ • evaluation outputs      │
                 │ • accumulators            │
                 └───────────────────────────┘

Context would be the sole evaluation context and contain every input needed by tilde evaluation. It would replace InitContext; the shorter name is appropriate once no alternative context types remain.

VarInfo would be the current OnlyAccsVarInfo: a collection of accumulators containing evaluation outputs. The current value-storing VarInfo and DefaultContext would be removed.

The governing invariant would be:

• evaluation reads only from Model and Context;
• evaluation writes only to VarInfo;
• parameter values and transform state are never read from VarInfo;
• always pass model rng via Context. https://github.com/TuringLang/DynamicPPL.jl/issues/721.

Reusing previous values would require an explicit output-to-input conversion:

context = Context(rng, InitFromParams(get_raw_values(vi)), transform_strategy)
retval, vi = evaluate!!(model, context, VarInfo(accumulators))

This builds on the accumulator framework from #744, the explicit initialisation path from #955, linked-value accumulators from #1212, and the migration toward explicit evaluation in #1264. The analysis in #836 explains why removing linked values from VarInfo ultimately requires removing the old VarInfo.

TuringLang/Turing.jl#2803 removed VarInfo from the Gibbs component interface. TuringLang/Turing.jl#2863 removes the remaining GibbsContext dependency, allowing #1468 to remove DynamicPPL’s parent contexts.

The transition should preserve aliases where practical, but the final API should not retain two VarInfo types with different responsibilities.

Start by reading the existing Context, InitContext, VarInfo, OnlyAccsVarInfo, and DefaultContext implementations, along with evaluate!! and the linked accumulator and explicit-initialization work. Done means evaluation reads inputs only from Context and Model, writes outputs only to VarInfo, and the final API no longer retains two VarInfo responsibilities while preserving practical aliases where possible.