Improve implememtation details in experimental data structures

[PointKernel]

This PR fixes issues and adds new features requested by rapidsai/cudf#13807.

It:

• removes the requirement of the second hasher from double hashing must be constructible from an integer
• fixes an issue in map iterator != operator
• overloads map iterator access operator
• allows zero capacity container
• adds capacity_test back since several corner cases need to be exercised

[sleeepyjack]

h1==h2 isn't ideal. If two distinct keys suffer from a hash collision, they will follow the same exact probing pattern. Using two different hash functions reduces the likelihood of running into these so-called secondary clustering effects.

[PointKernel]

h1==h2 isn't ideal. If two distinct keys suffer from a hash collision, they will follow the same exact probing pattern. Using two different hash functions reduces the likelihood of running into these so-called secondary clustering effects.

Agreed. The following code will fail if the custom_hasher doesn't have an int ctor:

  auto my_probe = cuco::experimental::double_hashing<custom_hasher>(custom_hasher{});

This makes me realize that our current code is based on the assumption that only one hasher type is used in double hashing and the second hasher must have an integer ctor:

cuCollections/include/cuco/probing_scheme.cuh

Line 112 in 6bc62c6

__host__ __device__ constexpr double_hashing(Hash1 const& hash1 = {}, Hash2 const& hash2 = {1});

This is a too-restrictive requirement and using two identical hashers is the first step to lower the bar. I haven't figured out a way to avoid the secondary collision yet by following this idea.

[PointKernel]

h1==h2 isn't ideal. If two distinct keys suffer from a hash collision, they will follow the same exact probing pattern. Using two different hash functions reduces the likelihood of running into these so-called secondary clustering effects.

Changes reverted at 8ac0ee8 since it requires a larger scope of adjustment/cleanup and will be in a separate PR.