Have `extractNgramsFromDocument` catch the right exception in case extraction fails

Closes #481

See merge request !419

[graphql] get contexts for ngrams fix

See merge request !416

Resolve "API refactorings"

See merge request !412

This described in this comment:
#477 (comment 14458)

I repaste, for history:

- job timeout was 30 seconds only and this is a big zip file, so the job timed out in worker
- however, this was recently added https://gitlab.iscpif.fr/gargantext/haskell-gargantext/blame/dev/src/Gargantext/Database/Action/Flow.hs#L490 and the timeout wasn't caught and the worker continued happily
- the job finished normally (most probably)
- the job was restarted, because default strategy for timeouts is to restart a job
- for sending files, we use postgres large objects because it keeps our JSONs small
- when the job finishes, it clears definitely the large object so that we don't leave large, unused blob data
- however, that job was restarted and there was no more a large object to work on
- you got some sql error, but that wasn't the root cause

Solution is:
- don't catch any exception, but be careful and handle `Timeout` or `KillWorkerSafely`
- increase job timeout for file upload
- change timeout strategy for file upload to `TSDelete`, i.e. don't retry that job anymore

It's possible that the zip file error was caused by a timeout (60 sec)
for zip file which is too low.

I think that sometimes, when user refreshed page, the websocket
connection could hang and the user stopped receiving new
notifications. This is modeled after CentralExchange timeout.

This fixes
#478
There was no `markStarted` and so 'remaining' was always at 0, so the
frontend thought the job was done, even though it was getting
notification about 'succeeded' in that job increasing

Separate ngram extraction from document insertion

Closes #473

See merge request !415

Now the tests pass again, but crucially `insertMasterDocs` runs in a
single atomic DB update, meaning we can rollback cleanly in case
disaster strikes.

The `ExtractNgrams` typeclass _definition_ imposed a redundant
`HasText` constraint, forcing all the _instances_ to have `HasText`
defined even though the instance didn't make any use of that.

That is overly-rigid, and it has been fixed by this commit.

This commit refactors the flow code to generate the ngrams for
the master docs separately, and then it "commits" them later after such
docs have been associated with a `Node`.

706 dev graph parameters display

See merge request !407

Fix a bug in `buildPatterns` and friends

Closes #395

See merge request !413

The final `T` doesn't add anything. It also moves the `HasText`
constraint _outside_ the typeclass definition.

Update IGraph

See merge request !411

Fixes a bug in the implementation of `buildPatterns`. In particular,
when we are building a `Pattern`, we need to do so in a case insenstive
fashion, otherwise later in the call to `replaceTerms` we would be
calling this from `extractTermsWithList` that cast everything into
lowercase due to the use of `monoTextsBySentence`.

This means that before this commit if we tried to search "Map" into
the text "Map is what I use when I'm lost" we wouldn't get a match,
because the latter would be converted into lowercase first
(i.e. "map is what i use when i'm lost") and we were trying to look
for the string "Map" (i.e. the former) into the transformer, yielding
no matches.

Previously the generator was generating all sorts of unicode symbols,
which doesn't play well for things like tab separators, carriage returns
and other things.

Furthermore, we need to be careful to not use the same symbol set of
`isSep` when we generate terms, because we are simulating an ngrams
search in a document and ngrams do not contain those separators
(i.e. `k2(` is not a valid ngram, but `k2` is).