Use defvar for rust-top-item-beg-re instead

Since rust-top-item-beg-re hasn't been defined yet, using defvar instead of
setq is more appropriate here (and also silences compilation warnings).
Implement fallbacks for functions unavailable in older versions of Windows
rustc: Fix enum variant privacy across crates

The code in resolve erroneously assumed that private enums weren't visited, so
the logic was adjusted to check to see if the enum definition itself was public.

Closes #11680
Add documentation for Windows compatibility layer and remove unneeded attributes
Move Windows compatibility layer to libnative
std: Remove bump_box_refcount. Deprecated and unused. Deprecused.
std: Doc typos
std: Reorder definitions in cast

Prioritize `transmute` and `forget`.
std: Change names of transmute's type parameters

from L, G to T, U. I don't know what L and G mean.
T, U easier to understand.
std: Small doc tweaks
Change the biguint documentation example to reflect deprecated owned vector
std: Mark timeout methods experimental

This was intended as part of the I/O timeouts commit, but it was mistakenly
forgotten. The type of the timeout argument is not guaranteed to remain constant
into the future.
Correct attribute grammar in reference manual
std: Ignore a flaky test on freebsd

This test runs successfully manually, but the bots are having trouble getting
this test to pass. Ignore it on freebsd for now.
Remove FromIterator impl for ~[T]

As part of the shift from ~[T] to Vec<T>, recently ~[T] was made
non-growable. However, the FromIterator implementation for ~[T] was left
intact (albeit implemented inefficiently), which basically provided a
loophole to grow a ~[T] despite its non-growable nature. This is a
problem, both for performance reasons and because it encourages APIs to
continue returning ~[T] when they should return Vec<T>. Removing
FromIterator forces these APIs to adopt the correct type.

Furthermore, during today's weekly meeting it was decided that we should
remove all instances of ~[T] from the standard libraries in favor of
Vec<T>. Removing the FromIterator impl makes sense to do as a result.

This commit only includes the removal of the FromIterator impl. The
subsequent commits involve handling all of the breakage that results,
including changing APIs to use Vec<T> instead of ~[T]. The precise API
changes are documented in the subsequent commit messages, but each
commit is not individually marked as a breaking change.

Finally, a new trait FromVec is introduced that provides a mechanism to
convert Vec<T> back into ~[T] if truly necessary. It is a bit awkward to
use by design, and is anticipated that it will be more useful in a
post-DST world to convert to an arbitrary Foo<[T]> smart pointer.

[breaking-change]
Rewrite &[T].to_owned() to allocate directly

This used to create a Vec<T> and then call .move_iter().collect() to
convert to a ~[T]. We can't do that anymore, so construct the ~[T] in
place instead. This has the added benefit of avoiding an unnecessary
memory copy (from the Vec<T> to the ~[T]).
More fallout from removing FromIterator on ~[T]

A few methods in slice that used to return ~[T] now return Vec<T>:

- VectorVector.concat/connect_vec() returns Vec<T>
- slice::unzip() returns (Vec<T>, Vec<U>)
- ImmutableCloneableVector.partitioned() returns (Vec<T>, Vec<T>)
- OwnedVector.partition() returns (Vec<T>, Vec<T>)
Rename slice::unzip() to vec::unzip()

unzip() has nothing to do with slices, so it belongs in vec.
Move slice::raw::from_buf_raw() to vec::raw::from_buf()

Change from_buf_raw() to return a Vec<T> instead of a ~[T]. As such, it
belongs in vec, in the newly-created vec::raw module.
More fallout from removing FromIterator on ~[T]