Guard variance inference for params bound in non-variance context.

Before adding a variance constrant for a given early-bound param,
check if it was meant to be inferred.

To support the above, added `fn is_to_be_inferred` to
`variance::ConstraintContext`.
Extended `syntax::{fold, ast_map}` to include lifetimes.

Part of this required added an override of `fold_type_method` in the
Folder for Ctx impl; it follows the same pattern as `fold_method`.

Also, as a drive-by fix, I moved all of the calls to `folder.new_id`
in syntax::fold's no-op default traversal to really be the first
statement in each function.

  * This is to uphold the invariant that `folder.new_id` is always
    called first (an unfortunate requirement of the current `ast_map`
    code), an invariant that we seemingly were breaking in e.g. the
    previous `noop_fold_block`.

  * Now it should be easier to see when adding new code that this
    invariant must be upheld.

  * (note that the breakage in `noop_fold_block` may not have mattered
    so much previously, since the only thing that blocks can bind are
    lifetimes, which I am only adding support for now.)
Drive-by: `pprust::*_to_str` for TypeMethod, Method, and FnDecl.
Regression test.
Add result sanity check to `is_to_be_inferred`.

This version of `is_to_be_inferred` double-checks the result from
`inferred_map` by querying the `named_region_map` and `ast_map` and
then asserts that the `inferred_map` state is consistent with its own
findings.  (See issue 13261 for further discussion of the approaches).
auto merge of #13261 : pnkfelix/rust/fsk-fix-12856, r=nikomatsakis

Fix #12856.

I wanted to put this up first because I wanted to get feedback about the second commit in the series, commit 8599236.  Its the more invasive part of the patch and is largely just belt-and-suspenders assertion checking; in the commit message I mentioned at least one other approach we could take here.  Or we could drop the belt-and-suspenders and just rely on the guard added in the first patch, commit 8d6a005 (which is really quite trivial on its own).

So any feedback on what would be better is appreciated.

r? @nikomatsakis