That commit added support for bit fields in structs
by converting all pointer addresses to bits.
Instead of a byte-adressable heap we now had a bit-adressable heap,
and all pointer adresses were multiplied by 8.

That commit forgot (at least) one case where it was necessary to switch
from bytes to bits:
`ExpressionToFormulaVisitor.getPointerTargetSizeLiteral()`
would need to use `getBitSizeof()` instead of `getSizeof()`.
This breaks pointer arithmetic such as `p + 1` and was reported as #422.

However, if we fix this now, we see another problem:
`(char*)p - 1)` gives a different result than `(size_t)p - 1`,
because in the former the value of `p` is decremented by 8 (bits),
whereas in the latter the value of `p` is decremented by 1.
C code that assumes that these two expressions produce the same value
is treated incorrectly, which can be seen
(after changing getPointerTargetSizeLiteral)
for example in ldv-sets/test_mutex_true-unreach-call.i.

Yet another problem is that the size of pointers in formulas
was not increased, but of course pointers for a bit-adressable heap
are 3 bits longer than pointers for a byte-addressable heap.
This means that pointer values overflow too early currently
(though of course pointer overflow is undefined behavior).

Especially because of the resulting difference between pointer
arithmetic and int arithmetic, I see no chance of really fixing all
issues with the bit-adressable heap,
and thus this reverts r23909 and restores a byte-addressable heap.

This fixes #422 but breaks support for bit fields,
at least for those bit fields that are on the heap or which the
predicate analysis treats as if they were on the heap
(e.g., if there is aliasing of the struct).

I hope that I found all locations that r23909 changed
and all locations where code that assumes a bit-addressible heap
was added in the meantime.
I checked all callers of `TypeHandlerWithPointerAliasing.getBitSizeof()`
and `.getBitOffset()`.
In all these cases bit fields should now be safely ignored and reads
would be assumed to be non-deterministic, so this should only be
imprecise and not unsound (which the current solution is).

git-svn-id: https://svn.sosy-lab.org/software/cpachecker/trunk@29988 4712c6d2-40bb-43ae-aa4b-fec3f1bdfe4c