Emphasize ghcup and discourage use of system GHCs.

In #109, we encountered Arch users whose build failed because Arch
installs a GHC configured to use dynamic linking by default, and GHC
is relatively reluctant to use dynamic linking (and sensibly, too,
given that ABIs vary between releases of GHC). Though Arch users
should be able to work around this problem with careful use of
`new-configure` flags, I submit that we should strongly encourage
people to use sandboxed, statically-linked GHCs, rather than contort
our code to account for questionable decisions on the part of the OS.

Author: Patrick Thomson

README.md

@@ -96,6 +96,8 @@ Available options:
 
 ## Development
 
+`semantic` requires at least GHC 8.6.4 and Cabal 2.4. We strongly recommend using [`ghcup`][ghcup] to sandbox GHC versions, as system packages installed from OS distributions may not install statically-linked versions of the GHC boot libraries.
+
 We use `cabal's` [Nix-style local builds][nix] for development. To get started quickly:
 
 ```bash
@@ -108,7 +110,7 @@ cabal new-test
 cabal new-run semantic -- --help
 ```
 
-`semantic` requires at least GHC 8.6.4 and Cabal 2.4. We recommend using [`ghcup`][ghcup] to sandbox GHC versions. `stack` as a build tool is not officially supported; there is an unofficial [`stack.yaml`](https://gist.github.com/jkachmar/f200caee83280f1f25e9cfa2dd2b16bb) available, though we cannot make guarantees as to its stability.
+ `stack` as a build tool is not officially supported; there is an unofficial [`stack.yaml`](https://gist.github.com/jkachmar/f200caee83280f1f25e9cfa2dd2b16bb) available, though we cannot make guarantees as to its stability.
 
 [nix]: https://www.haskell.org/cabal/users-guide/nix-local-build-overview.html
 [stackage]: https://stackage.org