[REVIEW] New suballocator memory resource classes

[harrism]

This PR introduces a few new suballocator memory_resources. Depends on #319 for thread_safe_resource_adaptor.

• pool_memory_resource is a coalescing pool suballocator memory resource. The behavior is effectively the same as cnmem_memory_resource, except that it is not currently thread safe and the code uses STL containers rather than custom linked lists.
• fixed_size_memory_resource allocates fixed size blocks from a pre-allocated list (which can grow as blocks get used). Provides constant time allocation and deallocation for allocations that fit within its fixed block size.
• fixed_multisize_memory_resource allocates blocks from a specified range of fixed power of two block sizes. (e.g. the default is 256KB to 4MB).
• hybrid_memory_resource given two suballocators and a byte size threshold to determine which one to use, returns arbitrary size allocations. Typically this means using a fixed_multisize_memory_resource below a threshold (say 4MiB), and a sub_memory_resource above that threshold.

Tests for all of the above are added, and the tests have been consolidated a bit so they run faster.

This PR also makes the RANDOM_ALLOCATIONS google benchmark more flexible so it can be run for a requested allocator and a given number of allocations and maximum allocation size.

TODO:

• More documentation
• meminfo (or remove it [FEA] Deprecate and remove rmmGetInfo #305 ). Update: worked around this by adding a new base class function supports_get_mem_info which returns false for all the new resource types.
• Improve pool growth heuristic: smarter pool growth strategy reduces fragmentation, improves performance in conditions that previously suffered fragmentation.

This uses a geometric growth strategy: when the pool is exhausted, it grows pool by half the difference between maximum pool size and current pool size. If half the remainder is not sufficient for the requested size, it allocates all the remainder. If all of the remainder is not enough for the requested size, it does not grow the pool and the requested allocation fails.

This can reduce fragmentation compared to the original strategy (which just grows by the requested allocation), since growth chunks cannot be merged. e.g. if the pool is 1/2 available GPU memory, and then many small allocations come in which cause the pool to grow by small steps, the pool will be very fragmented. Growing geometrically reduces fragmentation by growing by much more than is requested.

Future PRs:

• Use events to support per-thread default stream
• Multi-device? May not be needed since the device can be set before creating a resource. However should probably check current device when allocating from CUDA to ensure its the same as the device the MR was created on...

[jrhemstad]

Non-blocking comment about const-ness, otherwise good to go.

[jrhemstad]

Suggested change

	std::size_t size_base_; // base of the allocation block sizes (power of 2)
	std::size_t const size_base_; // base of the allocation block sizes (power of 2)

[jrhemstad]

Since these are being used for on the fly exponentiation to compute sizes, there's a better chance the compiler will optimize that out if these are const.

[jrhemstad]

Suggested change

	std::size_t min_size_exponent_; // exponent of the size of smallest blocks allocated
	std::size_t const min_size_exponent_; // exponent of the size of smallest blocks allocated

[jrhemstad]

Suggested change

	std::size_t max_size_exponent_; // exponent of the size of largest blocks allocated
	std::size_t const max_size_exponent_; // exponent of the size of largest blocks allocated