Turning on the flag `-Wunused-packages` turns up a bunch of unused packages.
This commit removes them from `gargantext.cabal`.

(Note that `-Wunused-packages` is NOT turned on in this commit.
I tried to turn it on, but occasionally got a bunch of other warnings
which I didn't understand and couldn't get to reproduce reliably,
about packages that were supposedly added via the `-package` or `-package-id` option
(I don't know about that option) but are unused)

Some modules consist only of commented code. This removes them.

Many modules feature the `{-# OPTIONS_GHC -fno-warn-orphans #-}` pragma.
In many cases, this pragma has no effect (because there are no orphan declarations
in the module). In some other cases, a little bit of refactoring could make them
useless.

This commit removes the pragma only in those modules where removing it
changes absolutely nothing.

- edit bin/update-project-dependencies
- fix the values of :
  - sha256sum cabal.project
  - sha256sum cabal.project.freeze
- nix-shell $ ./bin/update-project-dependencies
- git add -u
- git commit

This commit maps the "Publish" action inside CodiMD/HedgeDoc to the
share URL feature.

This commit improves a bit the ShareURL internal API by wrapping the
returned URL into a proper `ShareURL` type (that internally uses a typed
representation for the URL).

Fixes #374 by not using a bespoke config file, but rather setting
the `window.domain` and `window.urlpath` via regex substitution.

This avoids using an old `window.version` that would cause the
refresh modal to popup every time after each upgrade of HedgeDoc /
CodiMD.

The new files in `docs/` explain:
1. How to get one's editor to play nice with HLS
   and the Gargantext project
2. To interact with the server/database from within GHCI

A reference to them has been added to the `README`.

This time I think I am clear on what the building & running process is
and what the purpose of each command is, and I tried to make it clear again.

This may be deemed too verbose:
- Maybe I went into too many basic details, I'll be happy to discuss
  what the right level of detail is;
- But I also think there are too many ways to do the same thing
  documented in the README. It might be worth settling on one recommended way,
  and documenting the rest in an appendix or something like that.