while Brier-based scores are symmetric, Contigency Table-based metrics
are not, so that a definition how what an "event" means is required.
A new optional parameter *events* is added to `evalp` (taking either
"high" or "low" as value).

so that specifying the template arguments become optional

Ultimately, the objective is for the user to be able to get the raw
sampled metric values, or the mean and standard deviation of the sampled
metric values, or a series of quantiles of the sampled metric values.
There are still problems with the standard deviation on rtensor, and
the computation of the quantiles does not work on n-dim expressions yet.
So the second and third options are not possible yet, so only the raw
values can be returned. Nonetheless, the machinery and the choice of
where to introduce the summary functionality could be implemented,
which is the purpose of this commit. A new parameter of the bootstrap
experiment called "summary" is added: it can be given a value of 0 (to
get the raw values). In the future, it would also take a value of 1 for
mean+std, and 2 for quantiles.

The bootstrapping method is based on a non-overlapping block sampling
with replacement, where the blocks are years of data. The number of
samples and the sample length (i.e the number of year blocks) are both
customisable.

The method is accessible both for deterministic and probabilistic
evaluation where a new axis is added. For now, the metrics for all the
samples are returned, but in the future, some summary statistics would
be implemented (e.g. quantiles or mean/standard deviation).

/!\ For determinist evaluation, the n-dimensional functionality became
    untenable such that the number of dimensions was fixed and
    restricted to 2D tensors.

New unit tests are included to test both the bootstrapping generator
and the numerical results obtained with the bootstrapping turned on.

An earlier implementation of the masking conditions assumed that the
conditions on streamflow would only be on the observations, but this is
not always the case. For example, reliability scores cannot be done on
the observed streamflow and need to be performed on the predicted
streamflow. So this is now possible as the condition syntax is changed
and now *q_obs*/*q_prd_median*/*q_prd_mean* in place of *q*.

In order to be an accessible parameter type for Python (and hopefully
R in the future) bindings, `std::string` needed to be replaced with
`std::array<char, 32>`, a fixed-length string type.

This functionality is inherited from `evalhyd-cli`. It allows the user
to provide conditions as strings to specify how to generate temporal
subsets. Conditions can be based on observed streamflow values (e.g.
q>800, q<=120) or on time indices (e.g. to select particular events).

This functionality is made available both for determinist and
probabilist evaluation, unlike in  `evalhyd-cli` where it was only
available for probabilist evaluation.

This is documented in the docstrings, and new unit tests are written.

The general approach is to "eliminate" the time steps where observations
or predictions are missing as early as possible in the algorithm. The
best approach seemed to update the user-provided temporal masks to
also mask those time steps with missing data.

An alternative approach would have been to create a view on the
observations and predictions, e.g. using something like
`xt::view(obs, ..., xt::drop(...))`, but this produces a non-contiguous
view which cannot be sorted with `xt::sort` later to determine the
quantiles.

This is documented in `evalp` docstring and new unit tests are added.

resulting in only checking the first metric (i.e. BS) repeatedly

since `xt::allclose` does not have a *equal_nan* like `xt::isclose`
(see https://github.com/xtensor-stack/xtensor/issues/1995), the
check is a bit more convoluted than before...

different thresholds may be required of different sites, e.g.
if based on streamflow statistics, which are intrinsically site-specific

different temporal subsets may be required of different sites, e.g.
if based on streamflow statistics, which are intrinsically site-specific

Internally, rather than using the multi-dimensional character of
tensors to compute all sites and all lead times at once, loops are
performed for each site and each lead time, in turn, in order to
minimise memory imprint. Although at the moment, the input tensors are
expected to feature the sites and lead times dimensions. If memory is
an issue, the user can still send smaller tensors with size 1 for those
dimensions and recompose multi-sites/multi-lead times output arrays
externally.

It seems that good practice for C++ applications is to only include
*public* headers in "./include" folder and keep source files and
*private* headers and implementation source files in "./src".

Since the metrics are typically summary statistics, their size is not
very big, so that using xtensor instead of xarray as a data structure is
not as critical as for input data. In turn, using xarray allows for
metrics of different sizes to be returned without unnecessary size 1
dimensions (e.g. when only one threshold is given, or when no temporal
masking is performed). So all output metrics are now returned in their
"natural" shape (e.g. 1D for mono-component metrics, 2D for
multi-component metrics), plus any additional dimension linked to
multi-thresholds, multi-masking, etc.

So that the files for the tests look like typical files `evalhyd` would
expect, rather than its transposed version.

This is because in the CLI, metrics is a sequence of unknown length,
so it was only possible to make it last positional parameters. In order
to keep the interfaces harmonised across Python/R/C++ APIs and the CLI,
metrics needed to be put last positional parameter.

i.e. `evalhyd::determinist::evaluate` becomes `evalhyd::evald`, and
`evalhyd::probabilist::evaluate` becomes `evalhyd::evalp`