Frequent rehashes when size is close to capacity

[edre]

In the new benchmark suite, for table sizes just under the capacity, inserting and erasing elements leads to frequent resizes and complete table rehashes.

For SIZE=895:
test insert_erase_std_highbits ... bench:  16,548,714 ns/iter (+/- 1,936,585)
test insert_erase_std_random   ... bench:  16,376,567 ns/iter (+/- 1,338,857)
test insert_erase_std_serial   ... bench:  14,408,640 ns/iter (+/- 2,043,451)

For SIZE=896:
test insert_erase_std_highbits ... bench:      61,495 ns/iter (+/- 6,014)
test insert_erase_std_random   ... bench:      63,244 ns/iter (+/- 3,980)
test insert_erase_std_serial   ... bench:      60,410 ns/iter (+/- 13,798)

The benchmark is inserting and removing items in a loop keeping it at the given size, and once we generate one DELETED control byte we get pushed over the growth_left limit. We're then forced into a resize for a table of the same size as the one we started with. Ideally the amortized cost of insert/remove should be constant.

[edre]

For comparison, the absl hash table always doubles the size if it doesn't rehash in place from an insertion [1], but has different logic for reserve calls. [2]

[1] https://github.com/abseil/abseil-cpp/blob/aa468ad/absl/container/internal/raw_hash_set.h#L1579
[2] https://github.com/abseil/abseil-cpp/blob/aa468ad/absl/container/internal/raw_hash_set.h#L1219