[RFC] clar: known breakage - #4500

Printing out errors can be based on the type of error status. While
there is currently no status besides test failures which is to be
printed, we will introduce a failure type "Unbroken" soon. As such, add
the error status to the structure so that we're able to distinguish
errors and print them out differently.

Currently, we have no way to record known breakages in test suites. If a
projects knows of a certain way in which functionality is broken but
cannot yet fix it, it may want to record this fact. This provides some
benefits:

- breakage is recorded and easily discoverable, so that committers may
  pick out known breakages to pick up work

- it becomes possible to submit non-working tests first demonstrating
  breakage and later on submit a fix, switching over to a normal assert

- an error can be thrown as soon as the test is _not_ broken anymore,
  clearly highlighting when another change fixes breakage

This commit introduces a new state `CL_TEST_BROKEN` to mark a test as
broken. It also introduces a new macro `cl_break` which calls into the
new function `clar__broken`, which can be used to mark a test case as
broken.

Next to explicitly setting a breakage inside of a test with `cl_break`,
the most common scenario will most likely be to have known breakage on a
condition. This patch introduces a new set of macros `cl_must_break` and
`cl_check_break`. These macros cause a test to either be set to "broken"
if the assertion holds or, if it does not, to "failure". Like this, the
test can notify on both conditions:

- the system under test is still broken

- the system under test has been fixed and is not broken anymore,
  resulting in a failure

Note that a failure is the only reasonable thing to do. The authors of
the test suite certainly want to be notified as soon as known breakages
get fixed such that they can adjust tests and potentially e.g. remove
TODO items or bug tickets associated with the previous breakage.