Use ComplexityMeasures 3.8

[kahaaga]

Fixes #394, and closes #393.

What does this PR do?

Many files have changed, but mostly due to syntax changes for Documenter.jl (see comment below). The rest of the changes are:

•  Upgrade dependency version requirement from ComplexityMeasures which was hardcoded at 3.7 up to 3.8.
•  Quick fix: Moved GroupSlices code into a utils file in Associations.jl, since it no longer exists in ComplexityMeasures v3.8.
•  Use StableRNG for some tests, which were occasionally failing due to random data generation.
•  Use checkout action v5.
•  Set minimum julia version to long term stable release (1.10.10).
• The necessary changes add up to quite a bit more than a simple bug fix, so I upped the minor version.

Status

• Test pass
•  Documentation build is successful. I still need to fix this. Work underway.

[kahaaga]

Documentation changes

The documentation build was failing due to cross-reference and external cross reference issues that I did not manage to debug. They were due to updates in Documenter.jl. I want the doc system to be future proof. Therefore, I completely re-did how cross-referencing is done in the docs, according to the standards in the latest versions of Documenter.jl on using DocumenterInterLinks.

• The documentation now is completely stand-alone. It does not build the documentation from other packages. Previously, the docs for Associations.jl also built part of the docs for ComplexityMeasures.jl and StateSpaceSets.jl, which caused cross-reference issues and dead links with the latest versions of Documenter.jl)
• All types and methods references in the docs belonging to other packages (e.g. ComplexityMeasures.jl) are now referenced using an explicit @extref (e.g. [`OutcomeSpace`](@extref ComplexityMeasures.OutcomeSpace)). This eliminates all documentation cross-reference errors.
• Docs are now shorter (arguably cleaner), because of the external references. I'd prefer to maintain this way of documenting external references going forward, so we don't need to do double maintenance when it comes to docs (i.e. keeping the docs manually up to date in Associations.jl AND updating the docs in ComplexityMeasures.jl).
• Un-collapse all docstrings by default (since many pages are now shorter)

[Datseris]

awesome thanks! Yeah I also want to learn the cross referencing system! I'll use htis PR if I have to do it somewhere else!

[kahaaga]

@Datseris It took a bit of figuring out the cross-referencing , but what I had to do was basically precisely follow the recipe at the top of the recommended syntax page in the DocumenterInterLinks documentation. The syntax varies depending on what you're referencing from the external packages. For types and functions/methods, it turned out to be quite simple in the end:

If you've defined the external package links as

links = InterLinks(
    "ComplexityMeasures" => (
        "https://juliadynamics.github.io/DynamicalSystemsDocs.jl/complexitymeasures/stable/",
        "https://juliadynamics.github.io/DynamicalSystemsDocs.jl/complexitymeasures/stable/objects.inv",
        joinpath(@__DIR__, "inventories", "Documenter.toml")
    ),
    "StateSpaceSets" => (
        "https://juliadynamics.github.io/DynamicalSystemsDocs.jl/statespacesets/stable/",
        "https://juliadynamics.github.io/DynamicalSystemsDocs.jl/statespacesets/stable/objects.inv",
        joinpath(@__DIR__, "inventories", "Documenter.toml")
    ),
);

you can just refer to them in the docs markdown files as [My name for the link](@extref StateSpaceSets.sss_function). In contrast, "within package external referencing", e.g. [sss_function](@ref)), assumes that the modules argument to build_docs_with_style contains the package in which sss_function exists.

Mixing these two approaches gave some headaches and errors I wasn't able to resolve. Therefore, I ended up just doing build_docs_with_style(pages, Associations; ...), and using exclusively @extref for external docs. It may be possible to mix both approaches, but I didn't manage to figure out within a reasonable time frame how to do so.

Note: the approach described above also means you need to remove all docs blocks of the type

Type1
function1

where Type1 and function1 is in some external package that you previously included in the modules argument to build_docs_with_style. Instead, you need to manually create a list of links as

• [`Type1`](@extref ExternalPackage.Type1)
• [`function1`](@extref ExternalPackage.function1)

The docstrings themselves are only rendered in the external package documentation.