Multiple link-checking tools, unclear user API for docs building

Things that seem wrong

We have two sets of link checking stuff; somewhat more so after !377 (merged). We run mdbook-linklint on just the mdbook. And we have maint/check-doc-links which does some light seddery and runs linklint directly.

Also, we now have a number of scripts which build docs (or subsets of them), and/or check their links (or a subset of them). And our attitude to whether to check links seems inconsistent between local scripts, and CI.

Details, analysis

I don't think mdbook-linklint is buying us very much. The two regexp substitutions in check-doc-links seem sufficient to get linklint to be happy with both mdbook and rustdoc output. So, probably, we should get rid of mdbook-linklint.

The check-doc-links script is strictly more functional, since it checks cross-links between the rustdocs and the guide, assuming they use the canonical URL syntax. (In the public deployment these are cross-site links so not easy to check.) This comes with a theoretical downside: it requires rust tooling installed, as well as just mdbook. I think that's not an issue for derive-deftly.

There is a question: should we always do the checking, as part of the primary interface we advertise in HACKING.md? Currently the mdbook build always runs linkcheck, CI treats it as a warning, and the rustdoc builds depend on what script you run.

maint/check-doc-links is pretty fast. On my laptop it runs in 800ms despite nailing-cargo. So maybe we should make the primary interface be the one that does the check. That might mean renaming the build script or something, since otherwise it becomes a decoy entrypoint.

In any case presumably the inner build scripts shouldn't run linklint. We can expect everyone to either run our script that does it all, or cargo doc which is standard and works but doesn't build the book or check any links.

@nickm, opinions?