[#623] Make `show` harder to use

Description

Note: this MR is WIP, but is ready for review - I'd like to get opinions on the taken approach; or maybe just discouraging show will be found best.

Problem: our codebase is still full of show usages, some of them are wrong. Sometimes, show is a leftover after refactorings, during which using show stopped being justified.

Practice shows, that having a rule about show in our code-style is not enough, and it would be nice to try type system work on us here.

Solution: add a DebugShow constraint. It is supposed to be used with types having automatically derived Show instance; and for neatly printed types (like numbers), it is not necessary.

Now using non-pretty show requires explicit permission in form of wrapping the computation into allowDebugShow.

This solution seems sorta reasonable - normally machine-readable Show instances should not exist (in order to avoid leaking that into user interface), we generate these instances only for easy debugging. If so, it's nice to make show require debug permissions.

Cons of this approach:

• We can affect only our custom types this way;
• Verbosity of Show instance declarations;
• It is still the responsibility of the developer to use DebugShow where appropriate.

Pros:

• Existing methods that use Show (e.g. @?= from HUnit) are affected, they may require either explicit DebugShow permission, or using a wrapper to delegate to Buildable instance.

Related issue(s)

Resolves #623 (closed)

✅ Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • Root README and other README.md files
    • Haddock
    • docs/
  • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.