Support alternative `BitVector` implementations

[janvrany]

This PR reduces coupling between ArchC and MachineArithmetic in order to allow users to use alternative implementations of BitVector. This PR contains:

• changes to reduces dependency on MachineArithmetic to the point that ArchC depends only on class BitVector and (some of) its API
• an alternative, lightweight, pure-smalltalk, drop-in implementation of BitVector supporting APIs used by ArchC. The API is severly limited (like, bitvector length is limited to 62bits, not all operations are supported on symbolic bitvectors and so on).
• changes to baselines and makefiles to allow loading ArchC with alternative BitVector implementation.

By default, ArchC still uses BitVector provided by MachineArithmetic.

[janvrany]

FYI @melkyades , @KenDickey

[melkyades]

Nice! I was reading Click's thesis the other day and thinking "I will have to implement bit vectors eventually". There's also a need for BitVector-based sets, they should be implemented on top of this, thanks for sharing!

[janvrany]

@melkyades I did it in a way that you may use the one I started implementing here. I do provide a separate baseline to allow loading just bitvector without pulling in whole ArchC.

[janvrany]

After an internal discussion, we decided to keep this work in separate branch at least for a while. So I'm closing this PR and will eventually open a new one. The code now lives in branch alternative-bitvector-implementation in my fork (https://github.com/janvrany/Pharo-ArchC/tree/alternative-bitvector-implementation)