In preparation for incremental compilation this commit refactors the lint
handling infrastructure in the compiler to be more "eager" and overall more
incremental-friendly. Many passes of the compiler can emit lints at various
points but before this commit all lints were buffered in a table to be emitted
at the very end of compilation. This commit changes these lints to be emitted
immediately during compilation using pre-calculated lint level-related data
structures.

Linting today is split into two phases, one set of "early" lints run on the
`syntax::ast` and a "late" set of lints run on the HIR. This commit moves the
"early" lints to running as late as possible in compilation, just before HIR
lowering. This notably means that we're catching resolve-related lints just
before HIR lowering. The early linting remains a pass very similar to how it was
before, maintaining context of the current lint level as it walks the tree.

Post-HIR, however, linting is structured as a method on the `TyCtxt` which
transitively executes a query to calculate lint levels. Each request to lint on
a `TyCtxt` will query the entire crate's 'lint level data structure' and then go
from there about whether the lint should be emitted or not.

The query depends on the entire HIR crate but should be very quick to calculate
(just a quick walk of the HIR) and the red-green system should notice that the
lint level data structure rarely changes, and should hopefully preserve
incrementality.

Overall this resulted in a pretty big change to the test suite now that lints
are emitted much earlier in compilation (on-demand vs only at the end). This in
turn necessitated the addition of many `#![allow(warnings)]` directives
throughout the compile-fail test suite and a number of updates to the UI test
suite.

The field init shorthand syntax was stabilized in 1.17.0 (aebd94fd); we
are now free to use it in the compiler.

From review discussion on #38103
(https://github.com/rust-lang/rust/pull/38103#discussion_r94845060).

Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.

Resolves #42873.

Long ago, in the before-time, the find_lint method was created with the
unused_variables ("unused_variable" in the singular, as it was called at
the time) attribute in anticipation of using the session and span in the
handling of renamed lints (31b7d64f), and indeed, the session and span
came to be used in this method, while the unused_variables attribute
remained (1ad1e2e2). In modern times, the session and span are again no
longer used (ca81d3dd); it seems we can safely prune them from the
method signature, for justice, and mercy.

In the case of `TransCrateItem`, I had to tweak the tests a bit, but
it's a concept that doesn't work well under new system.

* #42007 happens because the Session LintStore is emptied when linting.
* The Session LintStore is emptied because the checker (Early/LateContext)
  wants ownership.
* The checker wants ownership because it wants to mutate the pass objects
  and lint levels.

The ownership of the whole store is not essential, only the lint levels and
pass objects need to be owned. Therefore, these parts are extracted out of
the LintStore into a separate structure `LintSession`. The "check crates"
methods can operate on `&mut LintSession` instead of `&mut LintStore`.

This is a minor BREAKING CHANGE for lint writers since the `LintContext`
trait is changed: the `mut_lints` and `level_stack` methods are removed.
But no one outside of `librustc/lint/context.rs` is using these functions,
so it should be safe.

This commit extends the current unused macro linter
to support directives like #[allow(unused_macros)]
or #[deny(unused_macros)] directly next to the macro
definition, or in one of the modules the macro is
inside. Before, we only supported such directives
at a per crate level, due to the crate's NodeId
being passed to session.add_lint.

We also had to implement handling of the macro's
NodeId in the lint visitor.

Previously, the note/message for the source of a lint being the command
line unconditionally named the individual lint, even if the actual
command specified a lint group (e.g., `-D warnings`); here, we take note
of the actual command options so we can be more specific.

This remains in the matter of #36846.

Warning or error messages set via a lint group attribute
(e.g. `#[deny(warnings)]`) should still make it clear which individual
lint (by name) was triggered, similarly to how we include "on by
default" language for default lints. This—and, while we're here, the
existing "on by default" language—can be tucked into a note rather than
cluttering the main error message. This occasions the slightest of
refactorings (we now have to get the diagnostic-builder with the main
message first, before matching on the lint source).

This is in the matter of #36846.

Otherwise they are a "hidden output"

Currently, late lint checking uses two HIR visitors: LateContext and
IdVisitor.  IdVisitor only overrides visit_id, and for each node searches
for builtin lints previously added to the session; LateContext overrides
a number of methods, and runs late lints.  When LateContext encounters an
item, it first has IdVisitor walk everything in it except nested items
(OnlyBodies), then recurses into it itself - i.e. there are two separate
walks.

Aside from apparently being unnecessary, this separation prevents lint
attributes (allow/deny/warn) on non-item HIR nodes from working
properly.  Test case:

// generates warning without this change
fn main() { #[allow(unreachable_code)] loop { break; break; } }

LateContext contains logic to merge attributes seen into the current lint
settings while walking (with_lint_attrs), but IdVisitor does not.  So
such attributes will affect late lints (because they are called from
LateContext), and if the node contains any items within it, they will
affect builtin lints within those items (because that IdVisitor is run
while LateContext is within the attributed node), but otherwise the
attributes will be ignored for builtin lints.

This change simply removes IdVisitor and moves its visit_id into
LateContext itself.  Hopefully this doesn't break anything...

Also added walk calls to visit_lifetime and visit_lifetime_def
respectively, so visit_lifetime_def will recurse into the lifetime and
visit_lifetime will recurse into the name.  In principle this could
confuse lint plugins.  This is "necessary" because walk_lifetime calls
visit_id on the lifetime; of course, an alternative would be directly
calling visit_id (which would require manually iterating over the
lifetimes in visit_lifetime_def), but that seems less clean.