Replace BloomFilter underlying BitSet with cats-collections immutable BitSet

[regadas]

See #716 for context.

Update: #716 (comment)

[johnynek]

If we are going to make a new implementation, I'd like to explore a pattern @non and I have found for parameterized monoids:

final class BloomFilter[A](hashes: Int, width: Int)(implicit val hasher: Hasher[A]) {
  sealed class BF[A] {
    def mightContain(a: A): Boolean
  }

  final case class BFInstance[A](toValue: A) extends BF[A]
  final case class BFSet(toBitSet: BitSet) extends BF[A]
  // ...

  def apply(a: A): BF[A] = ...

  implicit val monoid: Monoid[BF[A]] = ...
}

Then you use it with:

val bloomFilter: BloomFilter[A] = new BloomFilter(4, 1024)

val itemA1: bloomFilter.BF[A] = bloomFilter(a1)
val itemA2: bloomFilter.BF[A] = bloomFilter(a2)

val a3 = Monoid.plus(itemA1, itemA2)

Now, the type system prevents us from confusing bloom filter values from different parameter sets. Also, the serializers can be inside BloomFilter which knows the parmeters, so you don't need to serialize the parameters with each value.

[johnynek]

what do you think?

[regadas]

Sounds good! ... I've been meaning to pick this up again! I'll explore that!

A few notes around this PR:

• I moved the current impl to a legacy package ... I'll probably move it back (keep things as is) and add the new impl in a new package. (it will be opt in)

• I really think the BitSet impl as potential and as I mentioned in the comment, perf wise is on par and slightly better in some cases. When it comes to createBloomFilterUsingFold and createBloomFilterAggregator from More benchmarks for creating bloom filters #672 I saw significant improvements as well.

• I think you and @non already did some ground work in Improvements to BitSet performance and benchmarks typelevel/cats-collections#184 some things in this impl are a mix of that with the impl from master. Not sure what the move is ... if we cleanup that impl and merge it (we would depend on cats-collections) or we copy the impl (this gives us more freedom to tap into private mutable methods when needed to)

[regadas]

Closing this in favour of #840