Refactor RDF as an observable

[jngrad]

Folllow-up to #3599

Description of changes:

• replaced the RDF analysis tool by an RDF observable
• removed the particle position storage mechanism from statistics.cpp
• documented observable TimeSeries

[review-notebook-app]

Check out this pull request on 

Review Jupyter notebook visual diffs & provide feedback on notebooks.

---

Powered by ReviewNB

[jngrad]

The RDF observable is kind of a stand-alone class. If we decide to port calc_part_distribution to an observable (which is very similar to RDF) in the future, we might create an intermediate observable class that takes two lists of particle ids, but for now I'm somewhat ok with this architecture.

The time series documentation needs to be backported in 4.1.3.

[codecov]

Codecov Report

Merging #3706 into python will decrease coverage by 0%.
The diff coverage is 87%.

@@          Coverage Diff           @@
##           python   #3706   +/-   ##
======================================
- Coverage      88%     88%   -1%     
======================================
  Files         545     549    +4     
  Lines       24721   24747   +26     
======================================
+ Hits        21779   21787    +8     
- Misses       2942    2960   +18     

Impacted Files	Coverage Δ
src/core/statistics.cpp	67% <ø> (-11%)	⬇️
src/script_interface/observables/RDF.hpp	45% <45%> (ø)
src/core/observables/RDF.hpp	77% <77%> (ø)
src/core/observables/PidObservable.cpp	100% <100%> (ø)
src/core/observables/RDF.cpp	100% <100%> (ø)
src/core/observables/fetch_particles.hpp	100% <100%> (ø)
src/script_interface/observables/initialize.cpp	100% <100%> (ø)
src/utils/include/utils/for_each_pair.hpp	100% <100%> (ø)
src/utils/tests/for_each_pair_test.cpp	100% <100%> (ø)
src/core/particle_data.cpp	95% <0%> (-1%)	⬇️
... and 5 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff10b53...02af73a. Read the comment docs.

[fweik]

I'm not sure that comparison by value is what we want here. This limits the usability to value types that are comparable without need, and the behavior is different from for_each (which does it != first, e.g. shallow comparison), which is surprising. I think in the general algorithm the pairs should not be filtered, this can be implemented in the op. One could also implement a for_each_pair_if on if wanted.

[jngrad]

I was unsure about that solution too. If we remove that conditional, then we cannot decay this function to for_each_pair, since that one removes diagonal elements. In fact, we probably don't want to decay in any case, because for_each_pair also removes the symmetric pairs.

[jngrad]

I've coded a for_each_cartesian_pair_if and removed the decay to for_each_pair.

[fweik]

@KaiSzuttor did you have time to look at this?

[KaiSzuttor]

LGTM except for some small tweaks.