Distinguish __CPROVER_bool from _Bool in output

[tautschnig]

A __CPROVER_bool is a single bit and should not be output the same way as a
_Bool, which may be one or more bytes wide.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[kroening]

A mild warning: the front-ends still generate ID_bool in a couple of places, i.e., you might get __CPROVER_bool when outputting a program that didn't have any of that in it when you read it in.
An example are the boolean and relational operators.

[allredj]

This PR failed Diffblue compatibility checks (cbmc commit: a86c4d9).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/87984963
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

• the cbmc commit has disappeared in the mean time (e.g. in a force-push)
• the author is not in the list of contributors (e.g. first-time contributors).

The incompatibility may have been introduced by an earlier PR. In that case merging this
PR should be avoided unless it fixes the current incompatibility.

[tautschnig]

[...] you might get __CPROVER_bool when outputting a program that didn't have any of that in it when you read it in. [...]

Ack, but I'd suggest to wait for this to actually to be a problem anywhere, in which case we can start addressing it properly. Right now we are making those kinds of type conflicts very hard to see.