Until `external_traits` is cleaned up (i.e., no longer behind a
`RefCell`), `DocVisitor` will have to `take` `external_traits` -- just
like `DocFolder` -- to prevent `RefCell` runtime errors.

I think these are the last of the impls that can be easily converted to visitors.

Many of `DocFolder`'s impls didn't actually transform the syntax tree,
so they can be visitors instead.

* Flip conjuncts of `&&` in rustdoc

  The `CrateNum` comparison should be very cheap, while
  `span.filename()` fetches and clones a `FileName`.

* Use `into_local_path()` instead of `local_path().clone()`

One of the FIXMEs is irrelevant since that code is only run if
`include_sources` is set. I fixed the other FIXME.

`DocFolder` allows transforming the docs, accomplished by making its
methods take and return types by-value. However, several of the rustdoc
`DocFolder` impls only *visit* the docs; they don't change anything.
Passing around types by-value is thus unnecessary, confusing, and
potentially inefficient for those impls.

`DocVisitor` is very similar to `DocFolder`, except that its methods
take shared references and return nothing (i.e., the unit type). This
should both be more efficient and make the code clearer.

There is an additional reason to add `DocVisitor`, too. As part of my
cleanup of `external_traits`, I'm planning to add a `fn cache(&mut self)
-> &mut Cache` method to `DocFolder` so that `external_traits` can be
retrieved explicitly from the `Cache`, rather than implicitly via
`Crate.external_traits` (which is an `Rc<RefCell<...>>`). However, some
of the `DocFolder` impls that could be turned into `DocVisitor` impls
only have a shared reference to the `Cache`, because they are used
during rendering. (They have to access the `Cache` via
`html::render::Context.shared.cache`, which involves an `Rc`.)

Since `DocVisitor` does not mutate any of the types it's visiting, its
equivalent `cache()` method will only need a shared reference to the
`Cache`, avoiding the problem described above.

This simplifies the code and future-proofs it against changes to
`Variant`.

Also, contrary to the comment, the clone is not that small, since
`Variant` contains `Item`s, which are quite large when you factor in
both stack- and heap-allocated memory.

Now that #73423 is fixed, sorting should no longer be necessary.
See also this discussion [1].

[1]: https://github.com/rust-lang/rust/pull/86889#discussion_r664134963

It is not as large as `Crate.src` was, but it's still 8 bytes, and
`clean::Crate` is moved by-value a lot.

It is only used in one place; `src` was about a third of `Crate`'s total
size; `Crate` is frequently moved by-value; and `src` can be easily
computed on-demand.

We still had a number of places where underlined section headings would
show up, like under Implementations.

Don't display "Methods from Deref<...>" if no method is display (the ones which don't have `self` argument)

I think the new code is simpler and easier to understand.

The rustc fork of rayon integrates with Cargo's jobserver to limit the
amount of parallelism. However, rustdoc's use case is concurrent I/O,
which is not CPU-heavy, so it should be able to use mainline rayon.

See this discussion [1] for more details.

[1]: https://github.com/rust-lang/rust/issues/90227#issuecomment-952468618

Note: I chose rayon 1.3.1 so that the rayon version used elsewhere in
the workspace does not change.

Before, it was only measuring one callsite of `build_impl`, and it
incremented the call count even if `build_impl` returned early because
the `did` was already inlined.

Now, it measures all calls, minus calls that return early.

And add a rustdoc-gui test confirming various header sizes.

This generates more consistent HTML for these RefKeyWord combinations.

Before:

![image](https://user-images.githubusercontent.com/1593513/138742752-7e00a3f7-4621-4c62-82d1-3e4c2ef503d1.png)

After:

![image](https://user-images.githubusercontent.com/1593513/138743955-90abcdcd-fc88-4e2f-95bb-c1b1635c0001.png)

The makes the heading / documentation distinction clearer.

It should be preferred over `def_id_no_primitives()`, so it should have
a shorter name. I also put it before `def_id_no_primitives()` so that it
shows up first in the docs.

The old name was confusing because it's easy to assume that using
`def_id()` is fine, but in some situations it's incorrect. In general,
`def_id_full()` should be preferred, so `def_id_full()` should have a
shorter name. That will happen in the next commit.

In general, it should be preferred over `Type::def_id()`. See each
method's docs for more.

Now that it's only implemented for `Type`, using inherent methods
instead means that imports are no longer necessary. Also, `GetDefId` is
only meant to be used with `Type`, so it shouldn't be a trait.