build: also throw hash-mismatch errors if buildMode == bmCheck

This actually bit me quite recently in `nixpkgs` because I assumed that
`nix-build --check` would also error out if hashes don't match anymore[1]
and so I wrongly assumed that I couldn't reproduce the mismatch error.

The fix is rather simple, during the output registration a so-called
`delayedException` is instantiated e.g. if a FOD hash-mismatch occurs.
However, in case of `nix-build --check` (or `--rebuild` in case of `nix
build`), the code-path where this exception is thrown will never be
reached.

By adding that check to the if-clause that causes an early exit in case
of `bmCheck`, the issue is gone. Also added a (previously failing)
test-case to demonstrate the problem.

[1] https://github.com/NixOS/nixpkgs/pull/139238, the underlying issue
    was that `nix-prefetch-git` returns different hashes than `fetchgit`
    because the latter one fetches submodules by default.

tests/fixed.nix

@@ -21,6 +21,14 @@ rec {
     (f ./fixed.builder2.sh "recursive" "sha1" "vw46m23bizj4n8afrc0fj19wrp7mj3c0")
   ];
 
+  # Expression to test that `nix-build --check` also throws an error if the hash of
+  # fixed-output derivation has changed even if the hash exists in the store (in this
+  # case the hash exists because of `fixed.builder2.sh`, but building a derivation
+  # with the same hash and a different result must throw an error).
+  check = [
+    (f ./fixed.builder1.sh "recursive" "md5" "3670af73070fa14077ad74e0f5ea4e42")
+  ];
+
   good2 = [
     # Yes, this looks fscked up: builder2 doesn't have that result.
     # But Nix sees that an output with the desired hash already