Simple documentation build command

[mortenpi]

We probably want to move towards a more standardized and reliable docs build method. So my thinking right now is turning docs/make.jl just into a single Documenter command:

Documenter.build(package_directory)

It would then figure out some reasonable documentation build for that package environment. Key is that package_directory must be a valid package-type environment.

• First MVP would be something that just builds maybe the README + autogenerated list of (public) docstrings.
• Second iteration would automatically pick up .md files from the docs/ directory, allowing for a proper manual to be built.
• Next step would be to pick up some (limited) config options from the project TOML files, for customization (Declarative Documenter configuration #1350).

We should also create a GitHub Action, which instantiates the environment and calls this command. This way setting up docs for a package would become much simpler for the user (deployment side should also come in somewhere them, but Documenter.deploy() is available, and we can have enough metadata in siteinfo.js to determine the necessary deploydocs arguments I think).

A little bit unsure how to exactly handle environments here. Should there be a docs/Project.toml, that has Documenter? We definitely need to be able to Pkg.add Documenter together with the package though.

Note: this would not be for everyone. More complex manuals would still use custom make.jl setups. But I would hope that this would simplify the docs life for like 80% of packages.

Also some related discussion on Discourse: https://discourse.julialang.org/t/julias-documentation-needs-to-be-more-discoverable-and-explorable/106549

[mortenpi]

Something we also discussed with @fredrikekre: it would be nice to be able to build a documentation index of a current Project.toml (for the user) -- i.e. single page site that has all the docs for all the packages in your current project (could also be re-used by e.g. VS Code). The docs themselves could be built with Documenter.build, and then maybe aggregated with MultiDocumenter.

Long-running at-example blocks would be a problem here though. So we should probably have a mode where evaluating at-blocks is not enabled.

In the automated flow, we could potentially just have a timeout. If the docs don't build within a certain amount of time, we kill Documenter and build with the at-example disabled.. and if that fails, maybe just build fallback docs.