FlatMap: add Umpire support

[publixsubfan]

Summary

• Adds an Allocator wrapper class to disambiguate between integer arguments and allocator ID

  This is a speculative change, and I'd like to hear feedback from others: my biggest complaint/regret about the Array constructor interface is that we aren't fully drop-in compatible with the std::vector constructor interface, as we've sprinkled in allocator_id function arguments haphazardly. I'm hoping this might provide an alternative path forward that we can test out in FlatMap for now, and maybe bring it over into Array proper once fleshed out.

• Adds initial Umpire allocation support for FlatMap, supporting the following operations:

  • Creating a FlatMap within a custom Umpire allocator
  • Copying FlatMap between two different allocators, including device-based allocators
  • Destroying FlatMap created within a Umpire device-based allocator.

• Fix move assignment operator by returning reference to current instance

[bmhan12]

For consistency, I think it might make sense to make this getter a getAllocator() to compare Allocator's, and prevent the ability to access the int id's altogether.

[bmhan12]

Adds an Allocator wrapper class to disambiguate between integer arguments and allocator ID

I think this makes a lot of sense and helps guard against coding errors.
For reference, allocating an axom::Array using Umpire typically looks like some form of the following:

    axom::Array<int> my_array(
      size,
      capacity,
      allocator_id);

size, capacity, and allocator_id are all of type IndexType/int.

[kennyweiss]

I like this idea @publixsubfan -- it feels a lot cleaner than our current approach.

I'm eager to see what this would look like when applied to axom::Array and axom::ArrayView

[kennyweiss]

I like this idea!

[kennyweiss]

Should this be 0 by default? Or perhaps axom::INVALID_ALLOCATOR_ID
(which evaluates to -1 and is not a valid umpire allocator ID).

[kennyweiss]

Does/Will this also support hip? Or does hip not need extra handling?
If it's the latter, please add a comment.

[publixsubfan]

Yes, it's the latter case since with HIP we can access device memory directly from the host. I'll add a comment.

[adayton1]

That's true on some Hip platforms, but not all.

[kennyweiss]

Similar comment about hip here (and presumably elsewhere in this file)

[kennyweiss]

I suppose this would be our own idiomatic way to copy, but it's interesting!

[kennyweiss]

Just to make sure I understand -- test_map_device.size() is on the host, right?
Would we ever want the size to be on the device? If so, what would that look like?

[publixsubfan]

In this case, yes -- after this PR, I'm planning on pushing out another follow-up with a FlatMapView type for device-side accesses.

It'll be similar to the Array/ArrayView dichotomy, where the device accesses the data through the "view" type that is value-captured in the lambda.