Replace MPI_COMM_WORLD

While the tools can expect MPI_COMM_WORLD to be used, for applications using libmfu directly, it may be that they want to use a subset of procs for file I/O or they want to use the full set of procs but from a communicator other than MPI_COMM_WORLD. We need a way for the caller to provide the communicator as input.

Option 1: add MPI_Comm as argument to mfu_init(MPI_Comm):
One solution would be to pass a communicator to mfu_init(MPI_Comm) that we can dup and store in a global like mfu_comm_world. A simple replacement of MPI_COMM_WORLD with mfu_comm_world would work.

Option 2: add MPI_Comm to various mfu routines, like mfu_flist_new(MPI_Comm)
What if an application has multiple libraries, and each of those want to use libmfu independently? In that case, we'd need to provide a communicator per library. We'd either have to return some context from the call to mfu_init(MPI_Comm, &ctx) so that each can provide its own communicator, and then use that context as input to other calls like mfu_flist_new(ctx) or we could add a communicator as input to various routines like mfu_flist_new(MPI_COMM).

Option 2 is the most general solution, but it will require some more thought and significant refactoring. To allow any non MPI_COMM_WORLD solution, option 1 is a reasonable short-term improvement.

Start by tracing mfu_init(MPI_Comm), mfu_flist_new, and the current uses of MPI_COMM_WORLD in libmfu. Compare the proposed initialization communicator with the per-library context alternative, and check how other mfu routines receive state. Done requires an agreed API design and support for callers that use a non-MPI_COMM_WORLD communicator.