[FEA] Variadic ctor parameters

[sleeepyjack]

Part of #110 (Refactor of open address data structures)

Development branch: NVIDIA/cuCollections/refactor

Synopsis

To make it convenient to construct a static_set or other data structures with a variety of configuration parameters, we want to use a variadic constructor pattern.

TODOs

• Implement prototype: https://godbolt.org/z/T4oP1nsoW https://godbolt.org/z/Kj763Teon https://godbolt.org/z/5Ghac54E6
• To make this more generic, instead of the get_or_default<T> function looking for a concrete type T, it could look for the first type that satisfies a given concept C, e.g., get_or_default<C>. If necessary, use unique member tags to disambiguate a concept.
• Optional: Ctors that only take a variadic parameter pack (helpful to cuco::bloom_filter #101). For this, we need a mechanism to detect if all mandatory parameters are present, e.g., get_or_error<T>.
• refine prototype and fix nvcc build errors: https://godbolt.org/z/5Ghac54E6

References

• https://godbolt.org/z/T4oP1nsoW

[sleeepyjack]

Initial prototype: https://godbolt.org/z/Kj763Teon

This approach still needs some refinement but enables us to use fully variadic ctors if we opt for strong types for all parameters.
We could also use this in member functions to pass optional parameters,e.g., pass an optional CUDA stream to one of the bulk functions.

Build on gcc works but nvcc fails to understand the deduction guide. Investigating...

[sleeepyjack]

New version: tested on gcc, nvcc 11.0-11.7 and has better diagnostics: https://godbolt.org/z/5Ghac54E6