Do we still need parametric types in model definition for autodiff?

We currently use the following DynamicPPL syntax to support AutoDiff.

@model function f(N, ::Type{T}=Vector{Float64}) where {T}
    a = T(undef, N)
    a .~ Normal()
    m = sum(a)
    o = T(undef, N)
    o .~ Normal(m, 1)
end

We still need the parametric type (..., ::Type{T}=Vector{Float64}) where {T} for operator-overloading approaches like ForwardDiff and ReverseDiff. However, this is no longer necessary for Mooncake, which is source-transformation-based.

There might be a way to work around such requirements for ForwardDiff and ReverseDiff by implementing a (simple) model (AST) expression transform similar to Mooncake's. Such an approach is a bit speculative at the moment, but it is worth considering to simplify the modelling syntax.

cc @willtebbutt

Start by comparing the current DynamicPPL model syntax with Mooncake's source-transformation approach, then investigate whether ForwardDiff and ReverseDiff can avoid the parametric type requirement. Done means a clear decision or design direction for simplifying model definitions, including the implications for each autodiff backend.