Require partitioned grids for parallel runs instead of splitting them in EBFM? #205

EBFM splits non-partitioned grids over the MPI ranks itself: MATLAB and NetCDF grids and non-partitioned Elmer meshes (#197). Alternatively, every parallel run could require a grid that a preprocessing script has already partitioned into one part per rank, and output and restart files would be written per partition as well. For now we keep the internal splitting, since it is the most user-friendly approach.

Pros:

• Less code in EBFM: the internal splitting of Elmer meshes and gridded grids, the gathered output, and the gather/scatter of restart files (roughly 400 lines in src, plus tests).
• No rank reads more of the mesh than its own part. With the internal splitting, every rank reads the whole mesh first.

Cons:

• Users need a partitioned grid for every parallel run, and the number of ranks has to match the number of partitions, as in ElmerSolver. Running a partitioning on fewer or more ranks would need EBFM to merge or split partitions, i.e. the code this would save.
• When coupled to Elmer/Ice on a different number of ranks, EBFM cannot use Elmer's partitioning and needs one of its own for the same mesh (ElmerGrid can write several partitionings of one mesh; they keep the element ids).
• We need a partitioning scheme in the preprocessing script. ElmerGrid can partition Elmer meshes, but MATLAB and NetCDF grids have no partitioned format yet, and their slope and aspect need the neighbouring cells across partition boundaries.

The decomposition does not affect the results: EBFM columns are independent, and contiguous blocks of equal size already balance the load.