Since it removes the old iter::{range_inclusive, RangeInclusive} which
were unstable and deprecated, this is a [breaking-change] on nightly.

A whole bunch of stuff gets folded into struct handling! Plus, removes
an ugly hack from trans and accidentally fixes a bug with constructing
ranges from references (see later commits with tests).

The range desugaring does not use the lang items. Hence I did not add
lang items for inclusive ranges. This cleanup commit removes the old
unused ones as well.

Whether the desugaring _should_ use lang items is another question:
see rust-lang#30809. But if we decide on a strategy there we can add back these
lang items, and new ones for inclusive ranges.

For stage0 we need to keep the attributes as the lang items still exist
even if they are never used.

This is surprisingly not a breaking change. Unused #[lang] attributes do
not even trigger a lint (see rust-lang#30881).

Mostly copy the tests from half-open ranges, adding some more for
DoubleEndedIterator and ExactSizeIterator.

Also thoroughly (I think) test that the feature gates are working.

Since the desugaring removed special handling for ranges, the error
message changed and so I had to adjust `range-1`.

Turns out there was a bug where borrowck was too restrictive in some
rare cases of constructing ranges from literals. The `range-2` test
enshrined this bug -- now it's adjusted to test a case that's actually
wrong.

In particular, uses of inclusive ranges within the standard library are
still waiting. Slices and collections can be sliced with `usize` and
`Range*<usize>`, but not yet `Range*Inclusive<usize>`.

Also, we need to figure out what to do about `RangeArgument`. Currently
it has `start()` and `end()` methods which are pretty much identical to
`Range::start` and `Range::end`. For the same reason as Range itself,
these methods can't express a range such as `0...255u8` without
overflow. The easiest choice, it seems to me, is either changing the
meaning of `end()` to be inclusive, or adding a new method, say
`last()`, that is inclusive and specifying that `end()` returns `None`
in cases where it would overflow. Changing the semantics would be a
breaking change, but `RangeArgument` is unstable so maybe we should do
it anyway.