Separately track bitarray capacity

[etang-cw]

Fixes a bug where when resizing from > 64 bits to ≤ 64 bits, BitArray wouldn't realize that it was going to go from interpreting _data as a pointer to interpreting it as bits, and would fail to both free the pointer and copy its contents into _data, resulting in a memory leak, loss of the data in the BitArray, and a desync with the _lowestNeverClearedBitIndex and _clearedSectionCount variables. In the worst case scenario, such a resize when _lowestNeverClearedBitIndex was 0 would make future calls to setAllBits not set all bits, even though many bits were not set.

[billhollings]

Thanks for much for submitting this. And good catch and research!

This issue was causing the crash in #2271.

I've been sitting on an overhaul of BitArray that fixes this issue, and a few other things, including performance, because I didn't want to include a hefty change right before an SDK release, in case it unexpectedly affected other things.

So it's my bad that it's not out there yet. Sorry about that. I'll put that out in the few days.

[billhollings]

Superseded by PR #2355.