New feature: Allow QuEST to use a user-provided MPI_Comm

[otbrown]

This is largely for my own nefarious purposes, but is possibly useful to anyone seeking to simulate a hybrid quantum-classical application which is non-trivially parallelised. This functionality allows the user to define a separate MPI communicator for QuEST and avoid resource contention between simultaneous QuEST and non-QuEST parts of the program.

This shouldn't be too difficult to implement, but the interface might require a bit of thought, and in particular an elegant way to distinguish when finalizeQuESTEnv() should and should not also finalise MPI could be tricky.

Requirements:

• User should be able to provide an MPI_Comm at initialisation which QuEST will use exclusively.
• finalizeQuESTEnv should not necessarily finalise MPI.
• Tests should be written for all new functionality.
• Should not break existing codes therefore original QuESTEnv interface should be preserved, and should default to MPI_COMM_WORLD.

[otbrown]

Probably sensible to extend initCustomQuESTEnv for this and let initQuESTEnv do what it's always done.

[otbrown]

I've tried to come up with a way of doing this that doesn't involve conditionally including mpi.h in environment.h/cpp, as I was rather fond of the fact that only the source code in comm ever knew or cared that MPI exists. Unfortunately, every solution I can come up with is deranged, so we may just have to take our #if COMPILE_MPI medicine. The sticking points are:

• MPI communicators are of type MPI_Comm.
• MPI_Comm is defined in mpi.h.
• The MPI metadata held by QuESTEnv, rank and numNodes, are both dependent on the specific MPI communicator being used.
• QuESTEnv is deliberately immutable after initialisation.
• For the user to set a custom MPI communicator there must be at least one user-facing interface which includes MPI_Comm, so the absolute separation of the QuEST interface from mpi.h will have to be broken somewhere.