Merge of haskell-with-nixpkgs back into HNix

[Anton-Latukha]

This PR update build processes, both with CI processes:

• Migrates project to the GitHub Actions CI
  * ✔️ updates from Travis 50min restriction to GitHub 6 hours of execution time, which allows churning through Nixpkgs revisions that when Hydra CI Cache is not present (since Hydra CI cache has a pretty constant lag to after the channel update).
  * ✔️ faster node startup times
  * ✔️ much bigger number of nodes and the compute power of nodes
  * ✔️ Cachix and Nix deployment processes are better supported for GitHub Actions.
  * ✔️ multiple checks reported to PR, so the community can roughly see the info on build results even without going into CI interface. Find a CI that is able to pass multiple check results into GitHub #593
• ✔️ expands the number of builds: https://github.com/haskell-nix/hnix/pull/681/checks
• ✔️ allows to better customize and tune the build processes
• ✔️ introduces classical Cabal Hackage builds (8.{4,10}), that is mandatory for the Haskell project, Please, provide in CI the classical Cabal build #653
• CI updates:
  • ✔️ Nixpkgs GHC 8.8.(3->4), Please, update Nixpkgs GHC to 8.8.4 #683
  • ✔️ Nixpkgs drop of GHC 8.4.4, migration 8.4.4 to Hackage build, Please, remove from CIs the use of Nixpkgs GHC 8.4.4, since it is deprecated #684
• etc...

Also:

• ✔️ While waiting on GitHub CI Cachix key setup (Please, provide Cachix secret in HNix repository #682), reduced Travis, all builds become optional and added "bypass build" for fast skip, it is currently ours "green" background Cachix builder.

---

HNix was taken and with maximal preservation of Git history, Git history was
passed through pass filter and that in how haskell-with-nix was formed.

Further, work on CI and build configs happened there.

Due to HNix being a mothership project and since haskell-with-nix
preservation of original history - it is possible to merge progress from it
back.

Now, when haskell-with-nixpkgs main setup stabilized - it is ready to be
merged back, meanwhile HNix needed to dodge Nixpkgs downstream quirks which
blocked the development processes and new CI was needed.

Merge went pretty ideal, for merge haskell-with-nixpkgs only relevant history
was also filtered-out and also dropped 3 commits that got into the passed files.

A custom merge commit also was required.

But overall, the process of merge went unexpectedly great.

---

After the inside PR merge - also the change of stub names used in
haskell-with-nixpkgs to HNix-specific names is obviously needed. So that directly follows this
merge inside PR branch.

[Anton-Latukha]

Turned off GHCJS build

∵:

1. GHCJS build fails for months and nobody showed up to care and pursue it.
2. GHCJS build makes global CI report status ":heavy_multiplication_x:", and there is GitHub CI option to pass CI further and so also PR, but there is no way for GitHub CI to not propagate that ":heavy_multiplication_x:" to global marker.
3. Compilation of Haskell to JS was a half measure until there would be a better solution, since it is much more logical to compile Haskell to WebAssembly, and there is https://github.com/tweag/asterius for that.

⊢ GHCJS build test turned off.

If someone would actively pursue GHCJS
then we can enable it back
else there is no meaning to keep building and testing and looking at it

[Anton-Latukha]

About using 'DHall' and 'github-actions-dhall' for CI (answering message #681 (comment)), lets see further down the line.

I do no see the problem of having several files where everything is structured and laid-out in official GitHub way without use of additional utilites, and vast majority of people would never look or care about CI configuration further down the line, it is important but supplementary to the main goal - the project itself.

But when the people would look into GitHub CI configuration - they would work with the standard GitHub CI setup configuration.

[sjakobi]

LGTM based on my impression that this addresses some of our current CI woes.

If there are any issues we'll probably detect them while using the CI in anger.

Adding hundreds of commits to master for this CI overhaul seems a little disproportionate, so maybe this PR should be squashed.

Thanks for all the work, @Anton-Latukha, and thanks for addressing my concerns with the current CI setup! 👍

[Anton-Latukha]

Well, my view of it:

• commits should be small and atomic, note the steps of development, and so - be frequent and so have a footprint of development. And they are here. I just practice committing and tracking of the development.

• Every commit does a particular step, and action, since development is evolution, and the development footprint is there.

• Small commits are self-evident, and commit name often documentation of what and why was done.

• As I shown - Merge commits are abstractions over merged commits. In future I see only the workflows based on Merge abstractions.
  For example: I can take 670 commits, and organize them into merges by 10, then those by 10, we would get 1 main abstraction 7 sublevel abstractions, 70 subsubabstractions, 670 commits.

Specifically sitting and faking, retrofitting Git history is silly.
If some error or organization is on me - I always reorganize things on the spot locally.

---

The argument that there is some magic number of commits person needs to get into, while what matters is work done, and that the number of some commits and my number of commits different - is an argument of numbers, who likes which numbers.

While what primary - is results, and following a good practice.

And googling git best practices:

1. Git Tower: https://www.git-tower.com/learn/git/ebook/en/command-line/appendix/best-practices
2. https://deepsource.io/blog/git-best-practices/
3. http://sethrobertson.github.io/GitBestPractices/

---

Obviously I node towards this:

1. Small atomic commits is good
2. Small commits are self-documenting
3. Small commits mean great Git blaming
4. Small commits mean that during debugging (bisecting) person arrives directly towards the goal
5. Merge commits are perfect abstractions
6. Using merge commit abstractions with small commits inside them results in a more effective Git bisect algorithm.

What I mean, is that Git workflows can become much better.

[Anton-Latukha]

Thank you @sjakobi for the review.

---

I understand that my style sometimes may be seen as obnoxious.

I squashed everything into one commit.

My style honestly started from learning Git by doing, and Git was painful for me back in a dey, I used to not commit changes in time and created a small number of huge commits, so I started frequently commit unital atomic commits to get accustomed to Git commiting.

And, obviously, big commit numbers inspire respect both in person, and more importantly in the projects. And self-documentation, the following of the guidelines and developing effective practices - are a bonus.

If something - I encourage adoption of this style, since it arrives at many goals.

---

Thank you again, I am kneeling down for your work 🙏.

[sjakobi]

No worries, @Anton-Latukha! I appreciate your work on our CI! :)