Doing the _Bool cast stripping in LibraryFunctions doesn't completely work: EvalInt query on non-integers (like pointers) returns Bot to indicate the type mismatch instead of forcing it to an integer.

Having the assert analysis query with the cast added back (but not printed) seems to fix the issue, but I don't know of good of an idea that is.
The tests don't reveal this, but some analyses answer the EvalInt query by pattern matching on some binary expression. This no longer matches if there's a cast slapped in front.

One possibility to having Queries.eval_bool only add the cast for non-integer expressions (so binary comparisons don't get one). On the other hand, this makes things less consistent.
It also brings up the question whose responsibility it is to guarantee/handle/check what: the query asker or the query answerer.

I now merged in master and used Queries.eval_bool in place of the TODOs.

@michael-schwarz This reveals a problem in the bitfield domain. In particular, it doesn't handle casts to _Bool correctly:

[Warning][Integer > Overflow][CWE-190] Unsigned integer overflow (tests/regression/83-bitfield/08-refine-with-bitfield.c:89:5-89:31)
[Error][Assert] Assertion "a & 0x80" produces a bottom. What does that mean? (currently uninitialized arrays' content is bottom) (tests/regression/83-bitfield/08-refine-with-bitfield.c:89:5-89:31)

The overflow warning there is also spurious.

It has to do with the fact that we consider _Bool to be 1-bit, so according to the bitfield domain casting 128 to _Bool overflows and something breaks in the cast as well.