There are now three patterns (shallow, deep, and nested visit).  These
are described in detail on the docs in `itemlikevisit::ItemLikeVisitor`.

This commit does not change how the incremental accounting is done, so
changes (or accessses) to an impl-item are still tagged to the enclosing
impl.

This commits adds the "main guts" of this change. It does not build on
its own.

Basically adding `visit_impl_item` in various places and so forth.

This helps with incr. comp. because otherwise the Collect(Impl) check
winds up touching all of the impl items; since Collect(Impl) also
produces the types for the impl header, this creates a polluted graph
where the impl types depend on the impl items.

This is better because the edges will be accounted to
the impl item itself

This completes the effort to not touch the impl-items during
`Collect(Impl)`.

This allows you to enable *all* nested visits in a future-compatible
sort of way. Moreover, if you choose to override the `visit_nested`
methods yourself, you can "future-proof" against omissions by overriding
`nested_visit_map` to panic.

Before, when we created an AssociatedItem for impl item X, we would read
the impl item itself. Now we instead load up the impl I that contains X
and read the data from the `ImplItemRef` for X; actually, we do it for
all impl items in I pre-emptively.

This kills the last source of edges between a method X and a call to a
method Y defined in the same impl.

Fixes rust-lang#37121

Needed to keep coherence from freaking out.

Also simplify some of the `ty::AssociatedItem` representation,
in particular by folding `has_value` into `hir::Defaultness`

(Unrelated to this PR series)

This sidesteps problems with long paths because the canonical path
includes the "magic long path prefix" on Windows.