CG utils: implement ClebschGordanProduct and refactor DensityCorrelations

[jwa7]

Implements a general TensorCorrelator class and refactors DensityCorrelations to be built on top of this. The former allows the CG tensor product of two arbitrary TensorMaps (under some constraints, mostly to do with the metadata structure as explained in the class documentation), while the latter is a convenience class specifically for computing iterative density auto-correlations.

Closes #312

---

📚 Documentation preview 📚: https://rascaline--318.org.readthedocs.build/en/318/

[github-actions]

Here is a pre-built version of the code in this pull request: wheels.zip, you can install it locally by unzipping wheels.zip and using pip to install the file matching your system

[Luthaf]

I like the new TensorCorrelator, but I'm still not convinced by having a single DensityCorrelations for both self- and cross-correlations.

I would split it into something like SelfCorrelator and CrossCorrelator, maybe renaming TensorCorrelator to ClebschGordanProduct?

[jwa7]

I somewhat agree with splitting DensityCorrelations, but think its name should still point to the fact that these are density correlations (which is important for what it's actually doing). So I'd suggest DensitySelfCorrelations DensityCrossCorrelations.

And to be fair, thinking about it, I'm not sure DensityCrossCorrelations is even useful. An EquivariantTriSpectrumByPair (for instance) is p_i x p_i x p_i x p_ij, i.e. TensorCorrelator(DensitySelfCorrelations(p_i, n_correlations=2), p_ij), right?

There isn't a use case where doing density cross correlations is actually useful, because the building block is an arbitrary body order density auto-correlation, which is then correlated with a different density (or something else).

[jwa7]

So instead I think DensityCorrelations can just stay as being named like this, and the API changed to only accept a single density (not tensor and density), with the skip_redundant parameter having a single meaning where it is always valid.

DensityCorrelations then collapses back to what it always was before, a convenient way to compute density auto-correlations to arbitrary correlation order.

[Luthaf]

So instead I think DensityCorrelations can just stay as being named like this, and the API changed to only accept a single density (not tensor and density), with the skip_redundant parameter having a single meaning where it is always valid.

That sounds good to me!