…ICE-Consortium#377)

In fcbea1d (Added DMI/nuopc driver and fixed ANGLET (CICE-Consortium#377), 2019-11-22), the
computation in 'ice_domain::init_domain_blocks' that estimates 'max_blocks' if
the value '-1' is given in the namelist was changed without explanations.

The old computation was computing the number of blocks in the X and Y
directions, taking any necessary padding into account (by substracting 1 to
n[xy]_global, using integer division and adding 1), multiplying them to compute
the total number of blocks, and integer-dividing by `nprocs` to estimate the number
of blocks per processor.

The new computation does a similar computation, but it's unclear what it is
computing exactly. Since it uses floating point division and only casts the
result to an integer at the end of the computation, it systematically computes
a `max_blocks` value that is smaller than the old computation.

This leads to a `max_blocks` value that is systematically too small for the
cartesian decomposition when `block_size_x(y)` does not divide `nx(y)_global`
evenly.

Go back to the old computation.

Also, adjust the documentation to make it clearer that it's possible that
the `max_blocks` value computed by the model might not be appropriate.

The subroutines 'create_distrb_cart', 'create_distrb_rake' and
'create_distrb_spacecurve', in contrast to the other distribution-creating
subroutines in module ice_distribution, do not check if the index they are
about to access in the `blockIndex` array of the distribution they are creating
is smaller then `max_blocks`.

This results in an out-of-bound access when `max_blocks` is too small, and
potential segementation faults.

Add checks for these three distributions. Additionnally, for the cartesian
distribution, compute the required minimum value for `max_blocks`, which can
be done easily in this case, abort early, and inform the user of the required
minimum value.

…sition

As mentioned in the documentation, subroutines 'ice_blocks::create_blocks' and
'ice_distribution::create_local_block_ids' can print block information to
standard out if the local variable `dbug` is modified to ".true.".

For convenience, replace these local variables with a namelist variable,
'debug_blocks', and add a 'cice.setup' option to activate this new
variable in the namelist.

Adjust the documentation accordingly.

The value of 'max_blocks' as currently computed can still be too small
if the number of procs does not divide the number of blocks evenly.

Use the same 'minus one, integer divide, plus one' trick as is done for
the number of blocks in the X and Y directions in order to always
compute a 'max_blocks' value that is large enough.

This estimates the same value for 'max_blocks' as the 'cice_decomp.csh'
script computes:

    @ bx = $nxglob / ${blckx}
    if ($bx * ${blckx} != $nxglob) @ bx = $bx + 1
    @ by = $nyglob / ${blcky}
    if ($by * ${blcky} != $nyglob) @ by = $by + 1

    @ m = ($bx * $by) / ${task}
    if ($m * ${task} != $bx * $by) @ m = $m + 1
    set mxblcks = $m