[FEA] Have a global pinned memory pool by default

[vuule]

Users outside of Spark-RAPIDS still use the default, non-pooled, host memory resource and thus have the overhead of pinned memory allocations in hostdevice_vector, and any other places where pinned memory is used for faster data transfer.

Proposal: Default to a memory resource with a small pinned pool. When the pool is full, the resource should fall back to new pinned allocations to keep consistent with the old behavior when too much pinned memory is used.

To ensure we don't impact CPU performance, the default size of the pool can be a set percentage of the total system memory. Pinning a small minority of system memory (~5%) should not have a negative impact.

Initially, only hostdevice_vector would use this resource but we can expand the pinned memory use in libcudf once a default pool resource is in place.

Details to consider:
Pool should probably be created on first use - avoids duplicated pool is users set the resource before the first use.
Switching the host resource should work at any point, even if we must have two pools at the same time.
Can the default pool be safely destroyed? streams can't be destroyed on exit, not sure about cudaFreeHost

[vuule]

Measured memory use by hostdevice_vector in cuIO benchmarks as a percentage of peak device memory use. The pinned memory use is proportional to device memory use, so we can use the peak device memory use as a measure of how much pinned memory we would need if we used up all device memory.
The results show that we would never fall back to new pinned allocations with a pinned pool sized at 4% of device memory capacity. However, even at 0.5%, the pool can be used to allocate 90% of used pinned memory without additional allocations.

[vuule]

Benchmarking results:

"relative throughput" is the average ratio of the throughput with the custom resource and the throughput with default (pinned, non-pooled) resource.

Benchmarks consistently show improvement with pooled resource compared to pinned allocations.
read_json shows disproportionate improvement because of small benchmarks that are hugely impacted by a single pinned allocation.
Data also show that small pools bring very similar performance improvement to the pool that never falls back to new allocations.
Surprisingly, benchmarks also show that using pageable memory in hostdevice_vector is preferable to pinned (non-pooled).

TODO: run benchmarks from #15585 because we expect to see higher impact in multi-threaded use cases.