Use assert(Not)Regex instead of assertTrue or assertFalse in tests

[Flamefire]

This makes the tests shorter and hence easier to read, avoids
re.compile calls and manual failure message composing.
In some cases assert_multi_regex could be used to avoid the explicit loops.

While doing that I put the re.compile into the assertion instead of assigning to a variable and remove the call when there are no flags required as assertRegex accepts strings or compiled expressions

Examples:

-        regex = re.compile(os.path.join(tmpdir, r'easybuild-foo-1\.2\.3-[0-9]{8}\.[0-9]{6}\.log$'))
-        self.assertTrue(regex.match(res), "Pattern '%s' matches '%s'" % (regex.pattern, res))
+        self.assertRegex(res, os.path.join(tmpdir, r'easybuild-foo-1\.2\.3-[0-9]{8}\.[0-9]{6}\.log$'))

-        regex = re.compile(r"^eb toy-0.0.eb --robot --debug -l", re.M)
-        self.assertTrue(regex.search(txt), "Pattern '%s' should be found in: %s" % (regex.pattern, txt))
+        self.assertRegex(txt, re.compile(r"^eb toy-0.0.eb --robot --debug -l", re.M))

-            fail_msg = "Pattern '%s' should be found in: %s" % (guarded_load_regex.pattern, modtxt)
-            self.assertTrue(guarded_load_regex.search(modtxt), fail_msg)
-            fail_msg = "Pattern '%s' should not be found in: %s" % (recursive_unload_regex.pattern, modtxt)
-            self.assertFalse(recursive_unload_regex.search(modtxt), fail_msg)
+            self.assertRegex(modtxt, guarded_load_regex)
+            self.assertNotRegex(modtxt, recursive_unload_regex)

Continuation of #4205 , #4170, #5134 to remove usage of assertTrue & assertFalse as for almost everything there is a better alternative

Also regex assertions are over-used. In some places assertIn or even assertEqual could be used which is clearer and faster.
However the replacements done here were mostly regex-based with lot's of manual inspection to find good patterns, and finding those where assertIn would work is even more difficult.

Requires:

• enhance cmd.sh so it works in non-interactive mode, like when passing -c to run a command #5187

[boegel]

@Flamefire merge conflicts to resolve here...

[Flamefire]

Rebased

[boegel]

merge conflicts again...

As with #5223, I think it would help to break this into smaller PRs, which are easier to review/merge, and less likely to get blocked by merge conflicts

[Flamefire]

This is a search&replace (using regex) which I think is better to do once, especially as it is only test code so mistakes would a) turn up in CI and b) are not critical to users. So I would not recommend multiple PRs but just do some quick spot checking.

If you still want separate PRs: How small do you want them? More PRs is more work but quicker to review.