Add support for meshes in device memory in MFEMSidreDataCollection

[aaroncblack]

The Marbl code has test problems where the MFEM mesh data resides in device memory and has calls to the MFEMSidreDataCollection SetMesh() function.

The data collection source currently expects the MFEM mesh grid functions to reside on the CPU, as it is using the grid functions 'GetData()' to get the pointers to the data. These will return invalid host pointers if the grid function data is on the GPU.

I believe the source can be updated to support the MFEM mesh GF data in either cpu or gpu memory by replacing GetData() with HostRead() or HostReadWrite() calls to migrate the data if needed.

[rhornung67]

@aaroncblack Sidre allows a user to specify an Umpire allocator for a single Group or an entire subtree rooted at a Group. Wherever the allocator places allocations should be accesible through the data access methods. I'm not sure, but it would seem that MFEMSidreDataCollection could leverage that.

[aaroncblack]

@kennyweiss Hi Kenny, I chatted with Tom Stitt a bit on this.

For my use case, I hit some segfaults specifically on marbl problems that were running on the GPU where the hydro had migrated the MFEM mesh data, and then the MFEMSidreDataCollection tries to copy the Node data into Sidre with a GetData() call and segfaults because the host pointer is invalid.

He noted that this line would at minimum need to be replaced with a
GetData ->HostRead{Write}

https://github.com/LLNL/axom/blob/develop/src/axom/sidre/core/MFEMSidreDataCollection.cpp#L812

but he wasn't sure if that would be sufficient by itself, so recommended tagging to look at it.

I was able to get my tests working by adding a GetNodes->HostRead() call in the hydro, before MFEMSidreDataCollection was called, so didn't have to change anything in axom. I didn't test anything fancy though, for example a restart. thanks