Host allocation follow-on work

[rhornung67]

Noting some additional work items to pursue after #1964 is merged (assuming it does get merged). Rather than address these items in that PR to keep it smaller and focused, these items can be addressed in a future PR. These additional changes affect Axom APIs and semantics when behavior is not explicitly specified.

• Change axom::Array<T> to use AXOM_DEFAULT_HOST_ALLOCATOR choice rather than MemorySpace::Dynamic so that it's host allocation is consistent with the rest of Axom.
• Figure out how to avoid mixing AXOM_MALLOC enum value, which does not correspond to a valid Umpire allocator, with the rest of the enum values that do correspond to valid Umpire allocators.
• Change the name of setDefaultAllocator to setUmpireDefaultAllocator because the method only sets the default allocator in the Umpire ResourceManager?

Additionally, we will need a good way to test these changes in end user applications to make sure we don't break, or at least help them fix, their assumptions.