– Harmonize location output for warnings so that it is the same as for
  errors (i.e. more explicit about what is the line number and the column number)
– Remove obsolete stuff for delayed error messages that should have been
  removed in db1f6c29.
– Factorize some printing logic with ParsingDriver::undeclared_model_variable_error().
– Simplify WarningConsolidation class

The driver was calling “clear” before “global”, hence clearing local and not
global variables (unless “global” had already been called at scope).

Rather use “clearvars -global”.

– New “heterogeneity_dimension” statement
– New option “heterogeneity” to “var”, “varexo”, “parameters”, “model” and
  “shocks” statements
– New “SUM()” operator in “model” block

The vector of lower and upper bounds is now provided by
{static,dynamic}_complementarity_conditions.m (which accepts parameters as an
argument, in preparation for the possibility of having parameters in
complementarity conditions).

The index that denotes the reordering of equation residuals (so that the
residual of an equation appears at the index of the endogenous appearing in the
complementarity condition) is now in “M_.{static,dynamic}_mcp_equations_reordering”.

Constraints declared through the ramsey_constraints block are also incorporated
in this new interface (and therefore “M_.ramsey_model_constraints” has been
removed).

In particular, emit more explicit error messages in the presence of
inconsistencies.

Closes: #103

Closes: #124

In particular, makes clearer the distinction between configuration and
configuration file. The former includes information that is not in the
latter (command-line options.)

Ref. dynare#1907

The two are now compatible, even though the bytecode representation will not be
used.

“clearvars” has been implemented in Octave since version 5.

Adapt the code accordingly.

The implementation no longer relies on ramsey_policy.m at the MATLAB/Octave
level.

By the way, drop ModFileStructure::ramsey_model_present, which is now
redundant.

The check was only done with ramsey_policy.

It indicates the number of equations written in the model block by the user in
the discretionary policy case.

– M_.ramsey_orig_endo_nbr is the number of endogenous variables in the model
  present just before adding the Lagrange multipliers and computing the Ramsey
  FOC; it is by construction equal to the number of equations that will be added
  by the process of computing the FOCs
– M_.ramsey_orig_eq_nbr is the number of equations in the model present just
  before adding the Lagrange multipliers and computing the Ramsey FOC; it is by
  construction equal to the number of Lagrange multipliers that will be added by
  the process of computing the FOCs

Note that both may be greater than the number of endogenous/equations written
by the user, because some auxiliary variables may have already been added.

Also note that the number of policy instruments in M_.ramsey_orig_endo_nbr −
M_.ramsey_orig_eq_nbr

As a consequence, drop M_.ramsey_eq_nbr (which was actually equal to
M_.ramsey_orig_endo_nbr) and M_.orig_eq_nbr (which was actually equal to
M_.ramsey_orig_eq_nbr, but would also be set in the non-Ramsey case). The new
names are clearer.

And set them before any computation is done.

These fields should rather be in M_.

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

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

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.

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

As a consequence, and as a temporary measure, always output the
non-block-decomposed legacy representation.

Also drop the block kalman filter output, and drop now useless variables in
M_.block_structure.

Use std::filesystem::file_status and cached directory entries information to
avoid extra filesystem operations.

It is no longer used in the new implementation of solve_algo={12,14}.

However, the M_.lhs field that was created by setup_solvers.m is used from
other places, so reimplement it at the preprocessor level.

This is now possible since the block decomposition is always computed. Of
course, the information is not printed if the decomposition failed.

Ref. dynare#1859

The new representation is only supported for MATLAB/Octave, C and Julia output
for the time being. Bytecode and JSON are unsupported.

This commit adds new fields in M_.

This is a preliminary step for dynare#1859.

In that case, the block-DR routines will not be called.

This simplifes the treatment of the new sparse representation, which creates
several subdirectories in the “+” package folder.