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).

since those default values were only used to check whether these
parameters were provided or not, they are turned into optional
parameters

including:
- extracting the element/intermediate/metric calculations from the
  `determinist::Evaluator` class
- introducing new getter methods in `determinist::Evaluator` class
  that handle the element/intermediate/metric inter-dependencies
  internally to the object
- removing external inter-dependencies handling from `evald`

This is required for the bindings, because the 2D views on 4D tensors
must be on the correct type (i.e. pytensor/rtensor/xtensor). Although,
casting of the views to become xtensor could have been used instead.

In doing so, there is no source file to be compiled anymore, so this
becomes a header-only library. But to keep the "public" headers separate
from the implementation, a subdirectory "detail/" is added.

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.

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 it is not needed by metrics such as QS or CRPS

The order is which elements and dependencies are specified is important
because some may need to be computed before others (i.e. they are
themselves dependent). Using a vector (rather than a set) is required
because while the set is ordered, the order is not controlled by the
insertion order, but by some other sorting rules.

The purpose of such refactoring is to allow for a "memoisation" approach
(i.e. avoid re-computing the same elements/metrics multiple times).

By redefining the API as a one-entry point function `evaluate`
(as opposed to calling each metric in turn), it makes it possible to
know in advance the metrics required by the user, and by keeping a
register (hard coded for now) of what unitary computation elements
each metric requires, and which metrics are nested in other metrics,
it is possible to avoid computation repetitions.

Since arrays are row-major, and that the most costly reduction is along the time dimension, it makes sense to always have it as the last axis, so having a customised array orientation would not make this the case all the time. Dropping such support will also help with the documentation to state which axis corresponds to what.