CI automation

[Anton-Latukha]

Separate stages reported:

• CI reports a set of checks into PR (Find a CI that is able to pass multiple check results into GitHub #593)
• builds fine
• GHC {JS, stable{1,2,3}}
• tweak GHC warn messages
• test suites pass fine (currently as optional)
  • eval-okay-eq-derivations test inefficient, does not pass (>2 seconds) in macOS build
  • doHaddock requires tests - so is blocked
  • enableDeadCodeElimination 2020-06-02: NOTE: enableDeadCodeElimination = true: On GHC =< 8.8.3 macOS build falls due to https://gitlab.haskell.org/ghc/ghc/issues/17283, so temporarily set default to false
• benchmarks in time (optional)
• haddocks fine (succesful - mandatory, warns - optional)
• after master succesfull GHC 8.10 - require it
• Check that PR has (optional) Report mentioned (Make CI check the PR if its post linked to opened issue, and ask to open the Report #567)
• HLint (currently as optional)
• after master succesfull GHCJS - require it (better to go WebAssembly compilation)

GHC Wiki Haskell CIs overview: https://gitlab.haskell.org/ghc/ghc/-/wikis/continuous-integration

Stack / GitHub CI / hpc code coverage: https://medium.com/@_KtorZ_/continuous-integration-in-haskell-9ad2a73e8e46

Also related to CI: #305

[Anton-Latukha]

Three full days of work, and quite suprisingly good CI is ready: #583

[Anton-Latukha]

On features I try to provide and switch in default.nix, and CI:

• Nix-shell Cabal build is the least restrictive and so far the default way to build/develop.
• default.nix should be most versatile so less restrictive. It does not expect to have GHC optimizations enable, but I try to provide their options explicitly in the switches.
• CI should be the most restrictive to the code quality and consistency but have no GHC optimizations so would build faster. So even on this level build does not need GHC optimization of enableDeadCodeElimination and such.
• The release procedure should be one that is the most optimized.

[Anton-Latukha]

Adding the scanned for HLint rules is a big long-term gain, but also HLS HLint automation allows living without that.
Overall repository code is pretty clean from the lining point.

The only thing I think of - is maybe try to use Hercules-Ci or other Nix-first CI for something, and get projects more familiar one to another.