Address remaining issues with MFEMSidreDataCollection

[joshessman-llnl]

#318 moves the SidreDataCollection class from MFEM into Axom, but the feature is not enabled by default. Before this can be enabled, the following issues need to be addressed (per @kennyweiss):

• [x] Build the MFEM TPL with MPI when Axom is built with MPI, per https://github.com/LLNL/axom/pull/319#issuecomment-668985909 and https://github.com/LLNL/axom/pull/318#issuecomment-668661010 - #680
• [x] ~~Resolve an issue with sidre::IOManager not writing the protocol used to the file when saving, preventing visualization with VisIt when running in parallel~~ 2020-10-15: This appears to be working as expected - the provided example can be read in with VisIt when running in parallel
• [ ] Need to ensure that the convert_sidre_protocol example builds on Windows
• [x] (possibly) Construct GridFunction and Mesh objects when an MFEMSidreDataCollection is loaded from a file such that the state of the object is identical to the object that was saved - see https://github.com/mfem/mfem/issues/1776 - #379 and #445

[joshessman-llnl]

We should also look into eliminating the requirement that meshes/fields be explicitly constructed as "owned" by the datastore, see https://github.com/LLNL/axom/pull/379#discussion_r551672264

[joshessman-llnl]

Once reconstruction for parallel meshes is implemented we should look at ensuring coherency between the mfem::Mesh object and the contents of the datastore as refinement can cause them to diverge.

[rhornung67]

We should also look into eliminating the requirement that meshes/fields be explicitly constructed as "owned" by the datastore, see #379 (comment)

@joshessman-llnl we support this capability already if I understand your point. Indeed, this is how Miranda uses Sidre in MARBL.

[white238]

Random info to help finish this issue off:

convert_sidre_protocol is not being built in the Github Actions windows CI because MPI is off.

https://github.com/LLNL/axom/actions/runs/4120664761/jobs/7115614836#step:8:42