The problem was caused by the improper usage of
`delegate_ctrl` when creating the coreNLP process. For a long
time I was under the impression this flag was essential to allow child
processes to shutdown cleanly without leaving zombie threads, but the
result here in the context of the testsuite was that the coreNLP server
was receiving the first Ctrl^C, completely starving the Haskell RTS,
which wouldn't receive any and as a result our testsuite would be
running forever.

This commit uses the latest version of `gargantext-graph`, now rebranded
`gargantext-graph-core`, which allowed us to drop unused dependencies
like `accelerate-arithmetic` & co.

The recommended way to build GGTX is via cabal anyway, and stack
shouldn't get in the way of a successful build.

BREAKING CHANGE: this requires a newer version of `nix-shell`, at least
2.18 onwards. You can upgrade following the steps at:

https://nixos.org/download/

In particular, these are the bumped packages:

* GHC (9.4.8 -> 9.6.6)
* Cabal ( -> 3.12.1.0)
* Fortran ( 7 -> pinned)

[worker] various fixes

See merge request !389

Replace performance-critical parts of the algorithm with `massiv` (and ditch `accelerate-llvm`)

See merge request !382

We are now around 6/7 times slower than the LLVM code.

This also changes the cabal.project to not pull the accelerate-llvm or
the llvm-hs dependencies.

There are some rounding errors in the tests, but otherwise
the implementation seems correct.

It's crucial to be able to understand the API surface area when porting
the old code to `massiv`. It turns out that other than distributional,
the other piece of code using the LLVM interpreter is
`logDistributional2`.

This commit starts introducing `massiv` in the codebase,
initially for simple functions like `termDivNan`. The main
goal is to extend the linear algebra toolkit up to the
point where we can implement `distributional` in terms of
`massive` and measure its performance.

The previous code was sometimes yielding a matrix of NaN numbers as
it was attempting the division of the input matrix with the diagonal,
which would be 0 in case of an input matrix of 0, resulting in a
division by 0 error.