Avoid specializing all of ForwardDiff on every equation

[KristofferC]

ForwardDiff quite aggressively specializes most of its functions on the concrete input function type. This gives a slight performance improvement but it also means that a significant chunk of code has to be compiled for every call to ForwardDiff with a new function.

Previously, for every equation in a model we would call ForwardDiff.gradient with the julia function corresponding to that equation. This would then compile the ForwardDiff functions for all of these julia functions.

Looking at the specializations generated by a model, we see:

GC = ForwardDiff.GradientConfig{FRBUS_VAR.MyTag, Float64, 4, Vector{ForwardDiff.Dual{FRBUS_VAR.MyTag, Float64, 4}}}
MethodInstance for ForwardDiff.vector_mode_dual_eval!(::FRBUS_VAR.EquationEvaluator{:resid_515}, ::GC, ::Vector{Float64})
MethodInstance for ForwardDiff.vector_mode_gradient!(::DiffResults.MutableDiffResult{1, Float64, Tuple{Vector{Float64}}}, ::FRBUS_VAR.EquationEvaluator{:resid_515}, ::Vector{Float64}, ::GC)
MethodInstance for ForwardDiff.vector_mode_dual_eval!(::FRBUS_VAR.EquationEvaluator{:resid_516}, ::GC, ::Vector{Float64})
MethodInstance for ForwardDiff.vector_mode_gradient!(::DiffResults.MutableDiffResult{1, Float64, Tuple{Vector{Float64}}}, ::FRBUS_VAR.EquationEvaluator{:resid_516}, ::Vector{Float64}, ::GC)

which are all identical methods compiled for different equations.

In this PR, we instead "hide" all the concrete functions for every equation between a common "wrapper functions". This means that only one specialization of the ForwardDiff functions gets compiled.

Using the following benchmark script:

unique!(push!(LOAD_PATH, realpath("./models")))
using ModelBaseEcon
using Random # See https://github.com/JuliaLang/julia/pull/48810

@time using FRBUS_VAR

m = FRBUS_VAR.model
nrows = 1 + m.maxlag + m.maxlead
ncols = length(m.allvars)
pt = zeros(nrows, ncols);
@time @eval eval_RJ(pt, m);

using BenchmarkTools
@btime eval_RJ(pt, m);

This PR has the following changes:

• Package load time: 0.078s -> 0.052s
• First call eval_RJ: 11.47s -> 4.97s
• Runtime performance of eval_RJ: 550μs -> 590μs

So there seems to be about a 10% runtime performance in the eval_RJ call but the latency is drastically reduced.