[ENHANCEMENT]: Add hasher/comparator adaptor to better support mapping table use case

Is your feature request related to a problem? Please describe.

Many hash-based implementations rely on the mapping table method to handle large keys/values that are expensive to copy or move around. Every time users need to write the mapping table hasher/key_equal adaptors on their own, they shouldn't have to.

Describe the solution you'd like

As proposed by @esoha-nvidia, to better serve all users in this scenario, cuco could provide two handy utilities to the user:

1. mapping_table_hash wrapper constructed from a span (a pointer to the beginning of the original data and a size) and the original hasher
2. mapping_table_key_eq wrapper constructed from a span and the original key comparator

TODO:

• Add two utilities (probably in include/cuco/utility/mapping_table.cuh)
• Update the example accordingly
• Update godbolt link in README

Describe alternatives you've considered

Seeking help for better naming

• Is the mapping_table_ prefix descriptive enough? Any other suggestions?
• STL also use pred/predicate to refer to key comparators but I found mapping_table_key_pred/mapping_table_pred can be misleading since we support conditional operations like insert_if and contains_if where the condition is also named as predicate
• mapping_table_equal good enough? key_eq is the STL canonical but the _eq abbreviation is ambiguous.

Start with include/cuco/utility/mapping_table.cuh and compare the current mapping_table_example.cu usage. Review the naming questions alongside existing utility conventions, then update the example and the README godbolt link. Done means both adaptors are provided and all three TODO items are addressed.