ci: check Rust documentation

[arxanas]

Follow-up from #5052. This isn't critical, so we can drop this PR if we think it's not important or not worth resolving the outstanding questions for now.

Questions:

• What is our policy/strategy for new top-level checks vs embedding steps into existing checks?
  • I chose to make new top-level checks since I figured the feedback loop would be faster that way:
    • When a problem occurs, it's obvious at the top-level display that it's not a "real" test failure, just a rustdoc issue.
    • When you're fixing the problem, you don't have to wait the entire test suite.
  • However, it probably induces additional overall load to compile/process the codebase again?
• What is our policy for setting the Rust toolchain for the new checks?
  • I chose MSRV for the doctests themselves, since I imagined that they could demonstrate the API boundary, which needs to adhere to MSRV.
    • See below: we don't have any "real" doctests right now. So it's mostly immaterial for now.
  • I chose stable for cargo doc in case new lints get added.
    • It could be annoying to have to resolve lints that don't appear unless you have the latest stable toolchain.
    • We're already doing this for cargo clippy, so I don't think it should be much worse than the status quo?

Notes:

• These checks are mostly unrelated to the doc website generation.
  • Feel free to suggest any naming changes to the jobs/steps/etc. that make it clearer.
  • The exception is that website might process the same information from the CLI doc-comments, similarly to the original issue in docs: revert string formatting change of "jj help util exec" #5052, but this is incidental.
• We don't actually have any doctests at present.
  • So this mainly just detects "breaking the doctest build".
  • We might add some in the future to demonstrate how to use the library?
  • I confirmed that cargo test --doc catches the issue in docs: revert string formatting change of "jj help util exec" #5052.
• I fixed the few existing rustdoc issues.
• I highly recommend linking symbols in docs when possible (with square brackets, like [`Foo`]):
  • It makes the docs easier to navigate (both in the IDE and the crate documentation website).
  • With this PR, we can check validity of those references automatically to ensure the docs are up-to-date (via rustdoc::broken_intra_doc_links).
• In the current setup, I added new non-required top-level checks.
  • They're not "required" checks unless/until somebody goes into the GitHub repo configuration and adds them.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes