use size to decide which label class to use

Create `IntLabel`s where cardinality is small enough; otherwise, create
`BitSetLabel`s.
cache label hashCodes

`Label`s are hashed extensively, so cache their hash codes to save
time.
make label splitting more dynamic

Instead of always splitting into 4 or fewer lattices, aim for a maximum
cardinality of 5 per label, and split into as many partitions as are
needed to keep it there. This makes for a lattice size of 32, which
doesn't seem too bad. However, it might need tweaking in the future
(maybe 8 or 16 would be better).
fill hetero lattices in parallel

Speed up the `DistributedLattice` by filling `HeterogeneousLattice`s
in parallel using an `CompletionService`.

Update the `Labeler` implementations to be thread safe; previously
their lazy initialization of label partitioners led to threads stepping
on eachother. Also update the `Label` implementatinos to initialize
`hashCode` in the constructor instead of lazily. Lazy initialization
wasn't thread unsafe, but it did allow for multiple initializations to
happen, which is a waste of work for a method called so often.
create and use LongLabels

Create a new `Label`/`Labeler` pair called `LongLabel` and
`LongLabeler`. These use the exact same logic as as the `IntLabel`
pair, but the label bits are stored in a long so that the maximum
cardinality is 64 instead of 32.
remove unneeded block on cardinality

Since we now have labels using longs or bitsets, there is no need
to disallow large cardinality sets (although they may still not be
feasible).