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`