Have a common docs/tutorial interface for the whole JuliaGPs ecosystem

[theogf]

Once it's merged, we should do the same for the other packages:)
It would be nice if we didn't have to copy&paste the build scripts around. Could we make an JuliaGaussianProcessesDocUtils.jl package in which we bundle all these setups and export them as functions so that docs/make.jl could be a single function call (apart from using OurDocUtils, ApproximateGPs)?

Originally posted by @st-- in #97 (comment)

[st--]

And my follow-up:

Or would this be an argument for moving all the notebooks into a single JuliaGaussianProcessesTutorials.jl repo (as in SciMLTutorials)?

This might lead to more coherent documentation / intro.

Downside of that would be that we wouldn't immediately have them as integration tests for proposed changes anymore... 🤔

To preserve integration tests, maybe we could somehow include a "run all notebooks with current version of this package" in the build - whether by downloading [the relevant subset of] the examples and running them locally, or otherwise? - but by being in separate repos it would be harder to update them in sync?

[devmotion]

From my experience with Turing and associated packages I strongly recommend relying not only on a central repo of examples. It's difficult to keep them updated and generally leads to outdated documentation: If two or more packages in the ecosystem depend on each other but are not updated all basically at exactly the same time, then some of them will hold back the others in the docs. This happened very often in the Turing ecosystem due to the large number of, also external, dependencies and lead to outdated central docs. And the individual packages were basically undocumentes.

So I think it would be good to document each package individually, including separate examples. In addition it might be nice to have some central examples that eg show how multiple packages from ecosystem can be combined and used together. And probably these central examples could be updated a bit less frequently and it would be fine if they don't always use the latest version of each package.