[#415] Add general-purpose assertion helpers to Morley.Nettest

Description

These were some of the design choices I made, feedback is very much welcome:

1. We will eventually need to add assertions for collections (like the ones in hspec-expectations) to facilitate working with MorleyLogs. I didn't add them yet, because we're not yet sure what the API will look like. So I propose doing this only after/during #461 (closed).

2. I named the equality operators @==/@/=. persistent-test seems to use the same symbols, but I think it's extremely unlikely persistent-test and cleveland will ever be used in the same module, so clashing operator names shouldn't be a problem here.

3. @==/@/=/checkCompares use Show to display the values. I wasn't too sure whether to use Show or Buildable, but ended up going with Show because, in my opinion:

   1. The output of Show has the advantage of being copy-pastable back into source code.
   2. I would think Buildable is more suitable for applications to display nicely formatted data to the end-user (CLI apps, GUI apps, etc) and Show is more suitable for debugging/testing.
   3. There are more types with Show instances than types with Buildable instances.
   4. I'm pretty sure I've bumped into scenarios where two different values displayed the same string using pretty, but would have displayed different strings using show. I can't remember the specific type, sorry:confused:

   In any case, I also added checkComparesWith for versatility. If necessary, we could also export a Pretty newtype with instance Show where show = pretty for convenience (similar to this).

4. I'm not 100% sure I like the name checkCompares. I really wanted to call it shouldCompare, but using the should* prefix means later, when we add the collection assertions, we'll need to call them shouldContain / shoudNotContain, etc. These names will clash with hspec-expectations, which means we'll need to use them qualified. There's a good chance we'll want to use hspec-expectations and cleveland in the same module, and we'll want to use both unqualified, so I think avoiding name clashes is important.

   I ended up using the check* prefix, which we already use for checkBalance/checkStorage. checkCompares and checkContains sounds good. The negative checkNotContains sounds a bit weird 😩 but it's not a big deal, I think.

   Other possible prefixes: assert*, expect*, must*. IMO, none of these are a clear improvement over check*, at least not enough that would justify renaming the existing checkBalance/Storage functions.

Related issue(s)

Resolves #415 (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.