Bitvectors are now base 256

[kroening]

• 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).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[kroening]

This is a more radical alternative for #3107.
The key problem is that printing ireps no longer works.

[martin-cs]

1. I think this needs a rebase as one of the commits has been merged.

2. It's not clear how much of the second commit is also in Bitvectors are now hexadecimal #3107 ; they look quite similar. Does it make sense to get that one merged first?

[tautschnig]

Could the claim "This reduces the memory consumption of bit-vectors by 8x or more." be elaborated upon? We store strings in a lookup table, and thus this claim only applies for each unique entry. Do we have any measurements of the size of the string table at runtime? How many of its entries are bit vectors? I think we need much more data to trade the impossibility to print bitvectors for memory savings.

[kroening]

The current view is to go for hexadecimal representation, given that readability is important.

[TGWDB]

Closing as #3107 appears to be chosen over this one. Please reopen if you believe this is erroneous.