Error reporting improvements

In today's meeting, it was decided that error-specific Diagnostics classes will be introduced, but only later, so that we can quickly & easily create string error messages as long as things change quickly.

So this PR leaves error-reporting as string-based as it was before, and only makes a few improvements to error-reporting which should be applied already now. The advantages are the following:

*    debug output using the i interpolator does not fail any more due to uncaught SuppressedMessage exceptions
*    the i string interpolator is usable everywhere, not just in typer
*    Diagnostic does not store a reference to ContextBase any more
*    no mutable field suppressNonSensicalErrors in Context
*    no (unchecked) SuppressedMessage throwing
*    two additional small fixes (see the last two commits)

Instead of only the i string interpolator, there are now two: i and d. 

Originally, the i"..." string interpolator added three features to the s interpolator:

1)    On all Showables, `show` is called instead of `toString`
2)    Lists can be formatted using the desired separator between two `%` signs, eg `i"myList = (${myList}%, %)"`
3)    Detection of non-sensical error messages by throwing SuppressedMessage execptions

This PR removes 3) from the i interpolator, and adds the d interpolator, which does 1), 2) and 3), but instead of throwing SuppressedMessage execptions, it just marks the returned string with opening and closing "nonsensical" tags.

When should which interpolator be used:
*    d"..." if (the error message might be nonsensical) && (the string might end up in a Diagnostic)
*    i"..." otherwise


Ideally, d"..." would return a "magical data structure" which stores the message string and whether it's sensical or not (as sketched in today's meeting). However, this is not possible as long as we want to have all string operations (concatenation, stripMargin, interpolation, etc) on strings generated with d.

I agree that the way nonsensical error messages are marked in this PR is not very nice, and this PR is definitely not the final solution, but looking at the above list of improvements, I think it's still worth applying it.