collections::bitv: implement BitvSet directly as a Bitv
collections::bitv: Remove SmallBitv/BigBitv dichotomy

The old `Bitv` structure had two variations: one represented by a vector of
uints, and another represented by a single uint for bit vectors containing
fewer than uint::BITS bits.

The purpose of this is to avoid the indirection of using a Vec, but the
speedup is only available to users who

  (a) are storing less than uints::BITS bits
  (b) know this when they create the vector (since `Bitv`s cannot be resized)
  (c) don't know this at compile time (else they could use uint directly)

Giving such specific users a (questionable) speed benefit at the cost of
adding explicit checks to almost every single bit call, frequently writing
the same method twice and making iteration much much more difficult, does
not seem like a worthwhile tradeoff to me.

Also, rustc does not use Bitv anywhere, only through BitvSet, which does
not have this optimization.

For reference, here is some speed data from before and after this PR:

BEFORE:
test bitv::tests::bench_bitv_big        ... bench:     4 ns/iter (+/- 1)
test bitv::tests::bench_bitv_big_iter   ... bench:  4858 ns/iter (+/- 22)
test bitv::tests::bench_bitv_big_union  ... bench:   507 ns/iter (+/- 35)
test bitv::tests::bench_bitv_set_big    ... bench:     6 ns/iter (+/- 1)
test bitv::tests::bench_bitv_set_small  ... bench:     6 ns/iter (+/- 0)
test bitv::tests::bench_bitv_small      ... bench:     5 ns/iter (+/- 1)
test bitv::tests::bench_bitvset_iter    ... bench: 12930 ns/iter (+/- 662)
test bitv::tests::bench_btv_small_iter  ... bench:    39 ns/iter (+/- 1)
test bitv::tests::bench_uint_small      ... bench:     4 ns/iter (+/- 1)

AFTER:
test bitv::tests::bench_bitv_big        ... bench:     5 ns/iter (+/- 1)
test bitv::tests::bench_bitv_big_iter   ... bench:  5004 ns/iter (+/- 102)
test bitv::tests::bench_bitv_big_union  ... bench:   356 ns/iter (+/- 26)
test bitv::tests::bench_bitv_set_big    ... bench:     6 ns/iter (+/- 0)
test bitv::tests::bench_bitv_set_small  ... bench:     6 ns/iter (+/- 1)
test bitv::tests::bench_bitv_small      ... bench:     4 ns/iter (+/- 1)
test bitv::tests::bench_bitvset_iter    ... bench: 12918 ns/iter (+/- 621)
test bitv::tests::bench_btv_small_iter  ... bench:    50 ns/iter (+/- 5)
test bitv::tests::bench_uint_small      ... bench:     4 ns/iter (+/- 1)
collections::bitv: ensure correct masking behaviour

The internal masking behaviour for `Bitv` is now defined as:
  - Any entirely words in self.storage must be all zeroes.
  - Any partially used words may have anything at all in their
    unused bits.

This means:
  - When decreasing self.nbits, care must be taken that any
    no-longer-used words are zeroed out.

  - When increasing self.nbits, care must be taken that any
    newly-unmasked bits are set to their correct values.

  - When reading words, care should be taken that the values of
    unused bits are not used. (Preferably, use `Bitv::mask_words`
    which zeroes them out for you.)

The old behaviour was that every unused bit was always set to
zero. The problem with this is that unused bits are almost never
read, so forgetting to do this will result in very subtle and
hard-to-track down bugs. This way the responsibility for masking
falls on the places which might cause unused bits to be read: for
now, this is only `Bitv::mask_words` and `BitvSet::insert`.
collections::bitv: correct use of Vec<T>::grow

The argument passed to Vec::grow is the number of elements to grow
the vector by, not the target number of elements. The old `Bitv`
code did the wrong thing, allocating more memory than it needed to.
collections::bitv: remove some ancient interfaces

Removes the following methods from `Bitv`:

  - `to_vec`: translates a `Bitv` into a bulky `Vec<uint>` of 0's and 1's
    replace with:  `bitv.iter().map(|b| if b {1} else {0}).collect()`

  - `to_bools`: translates a `Bitv` into a `Vec<bool>`
    replace with: `bitv.iter().collect()`

  - `ones`: internal iterator over all 1 bits in a `Bitv`
    replace with: `BitvSet::from_bitv(bitv).iter().advance(fn)`

These methods had specific functionality which can be replicated more
generally by the modern iterator system. (Also `to_vec` was not even
unit tested!)
collections::bitv: replace internal iterators with external ones
collections::bitv: Add documentation and #[inline]'s

Add documentation to methods on BitvSet that were missing them. Also
make sure #[inline] is on all methods that are (a) one-liners or (b)
private methods whose only purpose is code deduplication.
collections::bitv: Implement several methods for `Bitv` and `BitvSet`

On Bitv:
   - Add .push() and .pop() which take and return bool, respectively
   - Add .truncate() which truncates a Bitv to a specific length
   - Add .grow() which grows a Bitv by a specific length
   - Add .reserve() which grows the underlying storage to be able to hold
     a specified number of bits without resizing
   - Implement FromIterator<Vec<bool>>
   - Implement Extendable<bool>
   - Implement Collection
   - Implement Mutable
   - Remove .from_bools() since FromIterator<Vec<bool>> now accomplishes this.
   - Remove .assign() since Clone::clone_from() accomplishes this.

On BitvSet:
   - Add .reserve() which grows the underlying storage to be able to hold
     a specified number of bits without resizing
   - Add .get_ref() and .get_mut_ref() to return references to the
     underlying Bitv
collections::bitv: change constructors for `Bitv` and `BitvSet`

`Bitv::new` has been renamed `Bitv::with_capacity`. The new function
`Bitv::new` now creates a `Bitv` with no elements.

The new function `BitvSet::with_capacity` creates a `BitvSet` with
a specified capacity.
collections::bitv: clean up and unit test `BitvSet::is_subset`
doc: reduce spacing of table of contents.

A margin for the top level list was leaking into nested ones.
Fix #12285

Unit-like struct patterns are irrefutable, no need for a branch.
simplify and uncomment item-fn-arg hygiene unit test
Fixed iOS build after *T removal
Removed LLVM bug workaround

It was required to get iOS compilable but since
that time a couple of changes were introduced
which cause the same bug to re-appear and broke 
build anyway. Fixing all of them doesn’t look a 
viable alternative to me as it will pollute the 
code too much.

So it should be fixed from LLVM side and I hope 
LLVM will upstream corresponding changes in a 
month.

Meanwhile, who wants to play with Rust on iOS is 
better to use a fork which uses patched LLVM:
https://github.com/vhbit/rust/tree/ios . It may 
lag behind master a bit, but it is Travis-checked 
to compile successfully.
librustc: Remove the `&LIFETIME EXPR` production from the language.

This was parsed by the parser but completely ignored; not even stored in
the AST!

This breaks code that looks like:

    static X: &'static [u8] = &'static [1, 2, 3];

Change this code to the shorter:

    static X: &'static [u8] = &[1, 2, 3];

Closes #15312.

[breaking-change]
auto merge of #15387 : huonw/rust/toc-space, r=alexcrichton

A margin for the top level list was leaking into nested ones.

before; after:

![screenshot from 2014-07-04 08 18 32](https://cloud.githubusercontent.com/assets/1203825/3476459/0b7f8ea8-0300-11e4-8b67-0c47b7931d56.png)
auto merge of #15388 : jakub-/rust/issue-12285, r=pcwalton

Unit-like struct patterns are irrefutable, no need for a branch.

And some cleanup while I'm at it.
trans::foreign: Simplify some code by using our builder impl
Fixed Result type parameters in doc comment.