The computing of the Ramsey steady state relies on the fact that Lagrange
multipliers appear linearly in the system to be solved. Instead of directly
solving for the Lagrange multipliers along with the other variables,
dyn_ramsey_static.m reduces the size of the problem by always computing the
value of the multipliers that minimizes the residuals, given the other
variables (using a minimum norm solution, easy to compute because of the
linearity property). That function thus needs the derivatives of the optimality
FOCs with respect to the multipliers. The problem is that, when multipliers
appear in an auxiliary variable related to a lead/lag, then those derivatives
need to be retrieved by a chain rule derivation, which cannot be easily done
with the regular static file.

This commit implements the creation of a new file,
ramsey_multipliers_static_g1.{m,mex}, that provides exactly the needed
derivatives w.r.t. Lagrange multipliers through chain rule derivation.

Ref. dynare#633, dynare#1119, dynare#1133

This is effectively a revert of commits 1b4f68f9,
32fb90d5 and f6f4ea70.

This transformation had been introduced in order to fix the computation of the
Ramsey steady state in the case where Lagrange multipliers appeared with a lead
or lag ⩾ 2 (and where thus part of the definition of an auxiliary variable).

But this transformation had introduced bugs in the handling of external
functions which were difficult to tackle.

Moreover, it seems preferable to keep the strict correspondence between the
dynamic and static model, in order to make reasoning about the preprocessor
internals easier (in particular, for this reason this transformation was not
implemented in ModFile::transformPass() but in ModFile::computingPass(), which
was a bit confusing).

A better solution for the Ramsey steady state issue will is implemented in the
descendent of the present commit.

Ref. dynare#633, dynare#1119, dynare#1133

If a given external function was called two times with different arguments,
then the second call would always be computed in the same temporary terms
chunk (derivation order or block) as the first call, even if this was not
necessary (technically, the second call would be promoted in the temporary
terms computation in the same category as the first call).

This could possibly lead to an inefficiency.

If an endogenous with a lead ⩾ 2 or an exogenous with a lead ⩾ 1 appeared in
the argument(s) of a call to an external function, the auxiliary variable
transformation was incorrect (the variable was replaced inside the function
call, while it is the whole function call that has to be replaced).

This could lead to incorrect results in stochastic contexts, when the external
function is nonlinear.

The first argument to ExprNode::computeTemporaryTerms() is supposed to be a
pair (endo derivation order, param derivation order). The two elements were
interverted in the call. This would not affect the result, because parameter
derivatives are not computed there and what matters is the lexical ordering
which remains the same. But fixing the order is better, for consistency with
the method description.

🐛 Crash when writing the (static) set_auxiliary_variables file in the presence of external functions

The output was in MATLAB syntax instead of Julia syntax.

It was erroneously using MATLAB costs, leading to possible
inefficiencies (though those cost tables are probably not very accurate and
should be revised).

By the way, remove a redundant Cluster{} constructor call.

Use map::{try,}emplace() instead of operator[], which should in theory be
slightly faster.

The argument had the same name as the data member “datatree”, so this could
lead to confusion (though there was no bug, since the argument was masking
the data member).

Previously, the MinGW location was appended multiple times to the PATH
variable, which in some cases would make the variable too long and thus
dysfunctional.

The variable is now initialized once when the worker threads are created.

By the way, move the macOS+Octave environment variable initializations to the
same place, for consistency.

- enforce x86-64 architecture
- use “sysctl -n hw.ncpu” instead of “nproc” (which has not been installed in
  the new runner)

Variable indices would be incorrect in the evaluated Jacobian if recursive
variables were present. This would lead to incorrect results and/or crashes in
bytecode MEX. This bug has been exposed by commit
f45a99fc, which actually enabled mfs>0 for
static models.

Commit 23b0c12d introduced caching in chain
rule derivation (used by block decomposition), which increased speed for mfs >
0, but actually decreased it for mfs=0.

This patch introduces the pre-computation of derivatives which are known to be
zero using symbolic a priori (similarly to what is done in the non-chain rule
context). The algorithms are now identical between the two contexts (both
symbolic a priori + caching), the difference being that in the chain rule
context, the symbolic a priori and the cache are not stored within the ExprNode
class, since they depend on the list of recursive variables.

This patch brings a significant performant improvement for all values of the
“mfs” option (the improvement is greater for small values of “mfs”).

Input and output ranges should not overlap when calling std::set_union(),
otherwise the behaviour is undefined.

It seems that in this precise case the computation would still be
correct (though inefficient), because of the properties of std::set or because
of the specific implementation in libstdc++. But it’s better to be on the safe
side.

In a dynamic context, the only potentially non-null derivatives of
STEADY_STATE(…) are the parameters. We know that the derivatives w.r.t. other
variables are zero, so store that information in non_null_derivatives.

- drop the Julia stuff, since it is no longer used
  In particular, no longer use static linking, since builds are now only
  for testing purposes and are not shipped
- drop the Windows i686 build, since we no longer support that configuration
- bump Boost version used for Windows x86-64 build
- rename build_linux_aarch64 into build_linux_arm64 for clarity

NB: mfs=3 is nevertheless used when “block” option has not been used, and the
model is purely backward/forward or static, for solve_algo={12,14}.

More precisely, incorrect equation normalization could occur in the presence of
cos, sin, tan, cosh and x^n (where n is an even integer).

Also add some comments explaining why some other rules are (hopefully) correct.

Closes: #113

No longer needed since perfect_foresight_problem MEX has moved to the sparse
representation.

Fix size of dynamic derivatives (legacy representation) when there are unused exogenous and “nostrict” option is given