* Abstract `isDistError`

There are two places in cabal codebase where `isDistError` is defined
(would Hackage refuse the package based on this error?), plus another
one in hackage-server (src/Distribution/Server/Packages/Unpack.hs).

This commit refactors the definitions into a singel `isHackageDistError`
(in Distribution.Client.Check) so everything is in sync. The function
is exported, for the benefit of third-party tools.

* Make `check` comply with Hackage requirements

`cabal check` exits with 0 or 1. As now the `1` exit is slightly
stricter than “Hackage would reject this”, as even PackageDistSuspicious
errors will trigger a `1` exit.

This patch rectifies this and also specifies the behaviour in the
documentation. Notice the usage of “should” and “will”: we cannot
be sure Hackage will accept a package (e.g.: maybe there are name
clashes) but there are no type I errors: if it fails `cabal check`,
Hackage will refuse it.

* Make testsuite pass

All the modified tests returned 1 on exit, now they return 0.

* Add changelog for #8897

* Expand catchall into constructors

(Andreas’ review) For `isHackageDistError`, so that in the future, when
constructors are added, the compiler will warn about missing them missing and
a thoughtful choice will be made.

* Use LambdaCase

(Artem’s review) Saves typing `isHackageDistError` four times more.

* Reword help strings

(Artem’s review) Make clear that errors will make `check` return 1.

* Fix typo

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>