WIP: Fix incorrect backtraces for errors in certain boolean expressions (DO NOT MERGE, but please discuss)

[fingolfin]

This is a bit like playing an endless game of whack-a-mole, or putting lipstick on a pig, of course -- the proper fix would be to rewrite the code tracking subexpressions inside statements, but that's a bigger change, so let's fix #3044 the simple way.

The first commit adds a couple of tests that reproduce #3044 and various more or less related issues.

The second commit fixes the problem, and updates the tests. By looking at just the diff for the second commit, you can thus easily see how those cases changed.

But after implementing this, I realized that there are many more similar issues, requiring lots of manual changes... or a sledgehammer approach to try to get rid of all of them at once. The third and fourth commit represent two different approaches to doing that, with different pros and cons. Note that the fourth commit is a hack, and probably introduces too much over head anyway, which is why I did not bother to clean it up; but it is good to see it "for comparison". Also, in fact, all of these changes may cause performance regressions, and should be benchmarked.

As discussed recently in St Andrews, even if one ignores all practical obstacles, part of the issue here is that it is not always clear what's "best" to print. I.e., even if we ignore the question "how to implement the desired behaviour?", it is not even clear what the desired behaviour is.

[ChrisJefferson]

If the overhead of the 4th commit isn't too great, it would be nice to handle this in one place -- and if we have to effectively put calls around almost every expression anyway, it might not be much slower