ompi/info: introduce support for the mpi_memory_alloc_kinds info object

[edgargabriel]

This PR introduces support for the mpi_memory_alloc_kinds and mpi_assert_memory_alloc_kinds info objects as defined in the MPI 4.1 document and in the side document specifying the values for the three supported accelerator kinds.
The logic is surprisingly twisted and I would not be surprised if some of the code here would have to be revised over time.

There are two ways on how the user can specify the mpi_memory_alloc_kinds info object: either as a runtime argument to mpiexec, namely -memory-alloc-kinds, or as part of the info-object passed to MPI_Session_init. There are two predefined memor-alloc-kinds, namely system and mpi, the latter having three potential restrictors. When user retrieves the info object e.g. using MPI_Comm_get_info on MPI_COMM_WORLD, the MPI library is allowed to return more memory-kinds than requested by the user.

This freedom has been applied in the following manner here:

• if the user does not request the system and/or mpi memory-alloc-kinds, we add them to the list of provided memkinds, in the case the mpi memory-alloc-kind fully spelled out with all three restrictors.
• if the user does not request one of the GPU memory kinds (cuda,ze,rocm), we do not add them to the list of supported memkinds, even if the library has been compiled with GPU support and it would be available. The goal is in a second commit to allow to use this mechanism to turn off GPU support in the library if support for GPU memory has not been requested by the user. This commit doesn't do that yet however.
• All unknown/unsupported memkinds are removed and not returned when retrieving the info object

This default memkind support is applied to all new {Comm/File/Window} objects, unless the user sets mpi_assert_memory_alloc_kinds during object creation (e.g. MPI_Comm_dup_with_info or MPI_File_open). The user can restrict the memory kinds supported by the object with mpi_assert_memory_alloc_kinds, i.e. setting this info object will influence mpi_memory_alloc_kinds on that object. I am not sure whether there is another example in the MPI spec where providing one info object influences the value of another info object, but the MPI 4.1 specification is pretty clear in my understanding that this is what is expected to happen.

Another difference in the handling of mpi_assert_memory_alloc_kinds is that if a provided value is not recognized, the entire mpi_assert_memory_alloc_kinds is dropped/ignored, not just the unrecognized memkind itself. (This is my reading of the specification on what is expected to happen).

---

Lastly, there could probably be some discussion whether the location chosen for the majority of the code is appropriate (i.e. ompi/info), a directory which so-far has contained the code to manage the MPI_Info object in general. After some discussion I thought this is the most appropriate locations, since

• this is MPI related know-how, i.e. it cannot go into opal
• the code is general and has to be used by Communicators, Windows, Files, and Sessions/Instances

[edgargabriel]

I will look into the mpi4py intercomm-create test failure on Monday.

[edgargabriel]

and the oshmem failure. Moving the status to WIP.