The problem has apparently been fixed in some update to R2024a.

This is a revert of commit 18131492.

By symlinking ~/.MathWorks to /dev/null, MATLAB is unable to copy and launch
the ServiceHost binary, which seems to cause lockups. See for example:
https://git.dynare.org/Dynare/dynare/-/jobs/62558
https://git.dynare.org/Dynare/dynare/-/jobs/62547

Ref. #1907

This replaces the old hack which was using a local Linux-specific symlink. Now,
the Dynare default is the same as in Sphinx, i.e. rely on a CDN for delivering
MathJax.

Adapt our CI accordingly to continue using MathJax from the Debian package
there (to avoid privacy issues related to the use of a CDN).

It had been inadvertently disabled in commit
16be3794.

By the way, switch the CI to use the Meson testsuite, because some test files
have been modified and no longer work with the old build system.

By the way, simplify the dependency build system by removing unused SLICOT
builds.

By the way, simplify the dependency build system by removing 32-bit
SLICOT (was only used for the Octave package), and the symlinks for MatIO and
GSL (no longer needed with Meson).

- enforce x86-64 architecture
- use “sysctl -n hw.ncpu” instead of “nproc” (which has not been installed in
  the new runner)
- use MATLAB R2022b for building with the latest ABI

Incidentally, no longer run Dynare++ unit tests, since they are intricated in
the Dynare++ build system. If we finally decide not to drop the Dynare++
codebase for our MEX files, then we should probably find a way to build and run
them again.

Ref. #1825