Rollup of 5 pull requests

- Successful merges: #46416, #46444, #46526, #46539, #46548
- Failed merges:

Recommends lazily evaluated alternatives for `Option::or` and `Result::or`

Adds language to docs for `Option` and `Result` recommending the use of lazily evaluated alternatives when appropriate. These comments are intended to echo a [clippy lint] on the same topic. The [reddit discussion] may also be of interest.

[clippy lint]: https://rust-lang-nursery.github.io/rust-clippy/master/index.html#or_fun_call
[reddit discussion]: https://www.reddit.com/r/rust/comments/7hutqn/perils_of_optionor_and_resultor/

Do not automatically merge `Cargo.lock`

It essentially never does what it's supposed to and often leaves the `Cargo.lock` in a state where it needs manual adjustments or resetting to master/yourbranch. With this setting git will always choose your `Cargo.lock` over the one from master and report a merge error (if both master and your branch touched `Cargo.lock`). Now you can run `./x.py help` and it should normally update the `Cargo.lock` to be one that has everything needed by master and your branch.

Greatly improve sidebar when width < 700px

Fixes #36531.

r? @QuietMisdreavus

A few screenshots:

<img width="1440" alt="screen shot 2017-12-06 at 00 41 36" src="https://user-images.githubusercontent.com/3050060/33636875-6ad8b1a6-da1e-11e7-8d5b-d6d530ea5258.png">
<img width="1440" alt="screen shot 2017-12-06 at 00 41 40" src="https://user-images.githubusercontent.com/3050060/33636876-6af58196-da1e-11e7-82ab-b82768958037.png">

Move colors to main.css

r? @QuietMisdreavus

doc: macro `cfg!` evaluating at compile-time

Modify message for keyword as identifier name

This is a temporary solution to #46311.

The message is generic enough to cover both cases and is probably a fine enough solution to the specific problem described in the task. However, the underlying reason for this to be wrong is that `next_token_inner` returns `Lifetime` even if the token is a label. That's not simple, as the syntax for both can be quite similar and it may need to take a look to the next token to make a decision. I'm not sure I have enough knowledge about the project to be able to solve that (yet!), so I thought I'll fix the immediate problem first.

Allow feature-gate tests to live in ui/ and migrate most of the tests from compile-fail

The PR consists of three commits:

1. change tidy to allow feature-gate tests to live in ui/
2. migrate some feature gate tests to ui/ with renaming only
3. migrate some feature gate tests to ui/ with also removing `// gate-test-...` lines and renaming them to the standard `feature-gate-<feat-name>.rs` format.

closure handling for NLL

This branch overhauls how we handle closures and universally quantified regions in the NLL code. The goal is to lay the groundwork for "region erasure" by the HIR-based type checker, as well as to avoid "crazy hacks" when it comes to closures. This means that when we type-check a closure, we cannot make use of *any* of the precise values of free regions in its signature, since those are inferred by the HIR type-checker. Therefore, the new code handles closures by:

- Creating fresh regions for every free region that appears in the closure's type, which now includes both its signature and the types of all upvars.
    - This means that the closure is type-checked without knowing about the connections.
- When we encounter some region relationship that we can't locally verify, we propagate it to the closure's creator.
- During MIR typeck, the closure creators then validates those relationships.

For a good example and explanation, see e.g. the test `src/test/nll/closure-requirements/propagate-despite-same-free-region.rs`.

Upcoming changes in the next NLL PR (not included in this PR in order to keep it manageable):

- Improvements to the MIR type checker so that it handles a lot of stuff presently overlooked
- Refactor how we store region values to make it more efficient, better encapsulated
- Propagate "type-outlives" relationships like `T: 'a` in a similar fashion to the one covered in this PR (still in the works, but close)
- Improvements to error reporting (still in the works)

r? @arielb1 or @pnkfelix

Update fingerprint tests macros

Part of #44924

r? @michaelwoerister

per pnkfelix's suggestion

suggested by arielb1

as suggested by arielb1

This includes the additional case suggested by arielb1.

It's just not useful. It also makes it hard to have tests that probe
internal state, since the interning number is very sensitive.

Dumping the number in the case of gensym is not ideal but will do for
now.

It's inefficient, and the substitution there doesn't account for the
extra regions used by NLL inference, so it's a bad thing to encourage.

As it happens all callers already know if they have a closure or not,
from what I can tell.

The overall format is now easier to read. Also, There is now graphviz
output, as well as a `#[rustc_regions]` annotation that dumps internal
state.

Speedup search loading when search url is received

Fixes #45971.

r? @nrc

cc @rust-lang/docs

We also rename some of the files to conform to the
feature-gate-<feat_name>.rs pattern that is most common.

Renames only in this commit, and obviously
.stderr file additions.

ui tests are the future, especially since the
recent improvement where we have gained
checking and requiring of //~ERROR comments.

The tidy feature-gate test check is intended
to be 50% an actual insurance that there is
a check, and 50% to be a teacher that such
checks are required.

With this commit applied, newbies might
interpret stuff wrongly and create tests
that don't fail but succeed instead.

This is not what feature gate tests are
for though. Therefore, in a later step,
when only ui tests are allowed to be feature
gate tests, we will add checking to ensure
that a file marked as gate test is actually
required to be a compilation failure.

Right now implementing such a check is a
bit annoying as one needs to only do it
when the compile-fail test is in the
ui test suite :/.