Closes #18126.

At the moment this mostly only changes notes that are particularly help-oriented or directly suggest the user to do something to help messages, and does not change messages that simply explain an error message further. If it is decided that those messages should also be help messages, I can add them to this PR, but for now I’m excluding them as I believe that changing those messages might leave very few places where notes would be appropriate.

There's currently a bug in it which fires erroneously on cross compiles,
preventing new nightlies from being generated. This can be reset back to Deny
once it's been fixed.

cc #18587

There's currently a bug in it which fires erroneously on cross compiles,
preventing new nightlies from being generated. This can be reset back to Deny
once it's been fixed.

cc #18587

Closes #18451

Implements a part of RFC 235.

[breaking-change]

- The `BytesContainer::container_into_owned_bytes` method has been removed

- Methods that used to take `BytesContainer` implementors by value, now take them by reference. In particular, this breaks some uses of Path:

``` rust
Path::new("foo")  // Still works
path.join(another_path) -> path.join(&another_path)
```

[breaking-change]

---

Re: `container_into_owned_bytes`, I've removed it because

- Nothing in the whole repository uses it
- Takes `self` by value, which is incompatible with unsized types (`str`)

The alternative to removing this method is to split `BytesContainer` into `BytesContainer for Sized?` and `SizedBytesContainer: BytesContainer + Sized`, where the second trait only contains the `container_into_owned_bytes` method. I tried this alternative [in another branch](https://github.com/japaric/rust/commits/bytes) and it works, but it seemed better not to create a new trait for an unused method.

Re: Breakage of `Path` methods

We could use the idea that @alexcrichton proposed in #18457 (add blanket `impl BytesContainer for &T where T: BytesContainer` + keep taking `T: BytesContainer` by value in `Path` methods) to avoid breaking any code.

r? @aturon 
cc #16918

Add lint for checking exceeding bitshifts #17713

It also const-evaluates the shift width (RHS) to check more complex shifts like `1u8 << (4+5)`.
The lint-level is set to `Warn` but perhaps it must be `Deny` as in llvm exceeding bitshifts are undefined as @ben0x539 stated in #17713

This PR:

* Adds the error interoperation traits (`Error` and `FromError`) to a new module, `std::error`, as per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md). Note that this module must live in `std` in order to refer to `String`.

    Note that, until multidispatch lands, the `FromError` trait cannot be
usefully implemented outside of the blanket impl given here.

* Incorporates `std::error::FromError` into the `try!` macro.

* Implements `Error` for most existing error enumerations.

Closes #17747

* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions

(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)

* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes

[breaking-change]

Made the fact that rodata is a section of the executable more explicit
Closes #18449

As per [RFC 70](https://github.com/rust-lang/rfcs/blob/master/active/0070-error-chaining.md)

Closes #17747

Note that the `error` module must live in `std` in order to refer to `String`.

Note that, until multidispatch lands, the `FromError` trait cannot be
usefully implemented outside of the blanket impl given here.

This makes the low-level allocation API suitable for use cases where
out-of-memory conditions need to be handled.

Closes #18292

[breaking-change]

After a snapshot, everything can be switched over and the small bit of hackery in resolve dealing with `ENUM_STAGING_HACK` can be removed.

cc #18478