This beefy commit removes the old (unnamed) Servant API.

This big commit ties the knot with the named _routes_ by providing
concrete server (i.e. handlers) implementations.

This big commit adds a separate module hierarchy for Servant named
routes (see https://www.tweag.io/blog/2022-02-24-named-routes/ ) which
will make working with servant endpoints more pleasant (especially when
it comes to emitted errors).

This still doesn't do anything to wire the routes to the concrete
handlers.

After Fabien's changes, this needed amendment.

This commit moves away from generic-derive JSON istances for `NodeType`,
as we know that the frontend will be relying on this in the GraphQL API,
and we don't want them to silently break the frontend during
refactoring.

It forces programmers to think about errors we are logging and reporting
to the frontend, because they need to contain no sensitive data.

Apparently `dot` has a long lasting bug (recently fixed) which is the
root of the non-determinism:

https://gitlab.com/graphviz/graphviz/-/issues/2510

This was (User, Either CorpusName, [CorpusId]) before, but the case of
UserMaster doesn't make sense with these parameters, so I rewrote the
function to accept only correct datatypes as inputs.

This contains only data, removes some Database dependency in imports.

This reverts commit f4284b4e.

This paves the way to a more effective search in corpus by modifying the
internal "leaves" type of the `Query` type from a `Term` to a new type
called `QueryTerm`, which can either be an extact match or a partial
match, which can be rendered into a proper Postgres TS query via the
":*" syntax.

Also, some test refactoring and add servant-client to tests.

This commit refactors ever so slightly the '.Stem' modules to create a
unified interface; now Gargantext.Core.Text.Terms.Mono.Stem exports a
single 'stem' function which can be used with different
`StemmingAlgorithm`s, and now the other algorithms' functions have been
shielded behind internal modules.

This makes possible to see at glance which part of Garg are using which
stemming algorithm, as it wasn't always clearer before.

This also allows us to have a better control over the langugages, as not
all the stemming algorithms supports all the languages that Garg
supports.

This reverts commit efbe327f, reversing
changes made to 6d9bcd07.

We have contexts.hash_id which is enough (computed by postgres as a
trigger).

Test failed, not merging.

This reverts commit 2e77bfa5, reversing
changes made to fe201115.

When user searched for a phrase with space inside, in database, the
'to_tsquery' function raised an sql error. One should use
'plainto_tsquery'. Also, a proper test was added.

Get rid of that TVar completely.