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

* 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]

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 also fixes #18490 as a side-effect by avoiding a later
out-of-bounds slice.

Closes #18126.

This prevents def IDs with the wrong crate ID from showing up
when using UFCS.  Closes #18501

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

Closes #18292

[breaking-change]

In some obscure circumstances, failure to do this can cause
unsubstituted type parameters to show up where they aren't
expected and cause an ICE.

Closes #18514

As part of the collections reform RFC, this commit removes all collections
traits in favor of inherent methods on collections themselves. All methods
should continue to be available on all collections.

This is a breaking change with all of the collections traits being removed and
no longer being in the prelude. In order to update old code you should move the
trait implementations to inherent implementations directly on the type itself.

Note that some traits had default methods which will also need to be implemented
to maintain backwards compatibility.

[breaking-change]
cc #18424

Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]

Closes #18487

As with last time (where I marked .woff files as binary so that git does
not perform newline normalization), it's unclear how it got corrupted in
the first place.

Browser-generated weights or slants is the last thing we want...