Avoid building as root with `sudo make install`

When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.

Related to #13728.
Add help diagnostic messages

This adds ‘help’ diagnostic messages to rustc. This is used for anything that
provides help to the user, particularly the `--explain` messages that were
previously integrated into the relevant error message.
Fix several issues with the struct and enum representability-checking logic.
auto merge of #16855 : P1start/rust/help-messages, r=brson

This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.

They look like this:

```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10             1 => {},
                        ^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```

(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
auto merge of #17009 : kballard/rust/install_no_sudo, r=pnkfelix

When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.

Related to #13728.
auto merge of #17815 : typelist/rust/recursive-structs, r=brson

The representability-checking routine ```is_type_representable``` failed to detect structural recursion in some cases, leading to stack overflow later on.

The first problem was in the loop in the ```find_nonrepresentable``` function. We were improperly terminating the iteration if we saw a ```ContainsRecursive``` condition. We should have kept going in case a later member of the struct (or enum, etc) being examined was ```SelfRecursive```. The example from #17431 triggered this issue:

```rust
use std::sync::Mutex;
struct Foo { foo: Mutex<Option<Foo>> }
impl Foo { fn bar(self) {} }
fn main() {}
```

I'm not 100% sure, but I think the ```ty_enum``` case of ```fn type_structurally_recursive``` had a similar problem, since it could ```break``` on ```ContainsRecursive``` before looking at all variants. I've replaced this with a ```flat_map``` call.

The second problem was that we were failing to identify code like ```struct Foo { foo: Option<Option<Foo>> }``` as SelfRecursive, even though we correctly identified ```struct Foo { foo: Option<Foo> }```. This was caused by using DefId's for the ```ContainsRecursive``` check, which meant the nested ```Option```s were identified as illegally recursive (because ```ContainsRecursive``` is not an error, we would then keep compiling and eventually hit a stack overflow).

In order to make sure that we can recurse through the different ```Option``` invocations, I've changed the type of ```seen``` from ```Vec<DefId>``` to ```Vec<t>``` and added a separate ```same_type``` function to check whether two types are the same when generics are taken into account. Now we only return ```ContainsRecursive``` when this stricter check is satisfied. (There's probably a better way to do this, and I'm not sure my code is entirely correct--but my knowledge of rustc internals is pretty limited, so any help here would be appreciated!)

Note that the ```SelfRecursive``` check is still comparing ```DefId```s--this is necessary to prevent code like this from being allowed:

```rust
struct Foo { x: Bar<Foo> }
struct Bar<T> { x: Bar<Foo> }
```

All four of the new ```issue-17431``` tests cause infinite recursion on master, and errors with this pull request. I wrote the extra ```issue-3008-4.rs``` test to make sure I wasn't introducing a regression.

Fixes #17431.
Add a lint for not using field pattern shorthands

Closes #17792.