CSD applied to Dansgaard-Oeschger events

[JanJereczek]

This PR mainly provides an example (docs/src/examples/do-events.jl) of Critical Slowing Down applied on the $\delta^{18}O$ record from NGRIP. This time series displays DO-events and therefore many abrupt transitions in real-world, paleoclimatic data. Furthtermore, the same analysis is performed on simulation data from CLIMBER-X (less noisy and even time sampling), an Earth Model of Intermediate Complexity able to reproduce DO-like events.

Remark: The time steps at which the DO-events are visible in the NGRIP timeseries come from Rasmussen 2014 and should be downloaded in future. For now, hand-coded. In the best case, this should be replaced by an automated procedure like those provided by ChangePoints.jl, which however did not give good results so far on the NGRIP data.

This PR additionally comes with minor suggestions:

• Use DocumenterCitations.jl as suggested and added refs.bib.
• The function segmented_significance() was introduced to perform the sliding window analysis such that a single significance value per segment and per indicator is output. This is subject to future changes since I want to introduce a new struct GrowingWindowViewer. We should discuss this live at some point.
• Replaced docs/src/tutorial.md by docs/src/examples/tutorial.jl such that the tutorial is built by Literate.jl.
• precompute_ridgematrix was renamed to ridgematrix since it simply computes the matrix.

[JanJereczek]

estimate_indicator_changes and significant_transitions now rely on multiple dispatch, by accepting SlidingWindowConfig<:WindowedIndicatorResults (renamed) or the newly introduced SegmentWindowConfig<:WindowedIndicatorResults. The latter requires the user to provide the start and end time of each segment into the config. To avoid any confusion about the functions performing the threaded loops, we now have two (internal) functions for this: sliding_surrogates_loop! and segmented_surrogates_loop!. For the sliding analysis, the t_indicator, t_change are simply vectors. For the segment analysis, they are each a vector of vectors: to me is the most intuitive way to handle the segmentation. Similar for x_indicator, which is a vector of matrices (dimensions of matrix as in in a sliding analysis). x_change is just a matrix with row index = segment index and column index = indicator index. Thus the user only computes one change metric value and therefore p-value per segment.

As suggested, we now use DocumenterCictations and the @cite macro.

Minor corrections were made to the DO-events example, especially the conclusions. It is still somewhat ugly that the transition times are hand-coded and we might want to make that more elegant in the future.

[Datseris]

For the sliding analysis, the t_indicator, t_change are simply vectors. For the segment analysis, they are each a vector of vectors: to me is the most intuitive way to handle the segmentation. Similar for x_indicator, which is a vector of matrices (dimensions of matrix as in in a sliding analysis). x_change is just a matrix with row index = segment index and column index = indicator index. Thus the user only computes one change metric value and therefore p-value per segment

I did not understand that. Can you please try to explain again what you said above? Additionally, please point me to the specific lines of source code where you are talking about so that it is easier for me to follow.

[Datseris]

@JanJereczek I merged this in. Notice that the PR violated the rule "do only 1 thing", as it actually did three things:

1. Expanded the API. With this PR we made it possible to add new different types for how to estimate change metrics and indicators.
2. Added a new way to estimate indicators and change metrics, the segmented window.
3. Added a new example.

However, that's okay for now, because all thse three things were tightly interlinked and we needed the example to see how the new interface could be used.