This commit moves the libserialize crate (and will force the hand of the
rustc-serialize crate) to not require the `old_orphan_check` feature gate as
well as using associated types wherever possible. Concretely, the following
changes were made:

* The error type of `Encoder` and `Decoder` is now an associated type, meaning
  that these traits have no type parameters.

* The `Encoder` and `Decoder` type parameters on the `Encodable` and `Decodable`
  traits have moved to the corresponding method of the trait. This movement
  alleviates the dependency on `old_orphan_check` but implies that
  implementations can no longer be specialized for the type of encoder/decoder
  being implemented.

Due to the trait definitions changing, this is a:

[breaking-change]

This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.

Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).

The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.

rules and cannot be updated until the libraries are synced, nor can
they opt in to the old semantics.

Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.)

This is a [breaking-change]. The new rules require that, for an impl of a trait defined
in some other crate, two conditions must hold:

1. Some type must be local.
2. Every type parameter must appear "under" some local type.

Here are some examples that are legal:

```rust
struct MyStruct<T> { ... }

// Here `T` appears "under' `MyStruct`.
impl<T> Clone for MyStruct<T> { }

// Here `T` appears "under' `MyStruct` as well. Note that it also appears
// elsewhere.
impl<T> Iterator<T> for MyStruct<T> { }
```

Here is an illegal example:

```rust
// Here `U` does not appear "under" `MyStruct` or any other local type.
// We call `U` "uncovered".
impl<T,U> Iterator<U> for MyStruct<T> { }
```

There are a couple of ways to rewrite this last example so that it is
legal:

1. In some cases, the uncovered type parameter (here, `U`) should be converted
   into an associated type. This is however a non-local change that requires access
   to the original trait. Also, associated types are not fully baked.
2. Add `U` as a type parameter of `MyStruct`:
   ```rust
   struct MyStruct<T,U> { ... }
   impl<T,U> Iterator<U> for MyStruct<T,U> { }
   ```
3. Create a newtype wrapper for `U`
   ```rust
   impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { }
   ```

Because associated types are not fully baked, which in the case of the
`Hash` trait makes adhering to this rule impossible, you can
temporarily disable this rule in your crate by using
`#![feature(old_orphan_check)]`. Note that the `old_orphan_check`
feature will be removed before 1.0 is released.

This commit is an implementation of [RFC 526][rfc] which is a change to alter
the definition of the old `fmt::FormatWriter`. The new trait, renamed to
`Writer`, now only exposes one method `write_str` in order to guarantee that all
implementations of the formatting traits can only produce valid Unicode.

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md

One of the primary improvements of this patch is the performance of the
`.to_string()` method by avoiding an almost-always redundant UTF-8 check. This
is a breaking change due to the renaming of the trait as well as the loss of the
`write` method, but migration paths should be relatively easy:

* All usage of `write` should move to `write_str`. If truly binary data was
  being written in an implementation of `Show`, then it will need to use a
  different trait or an altogether different code path.

* All usage of `write!` should continue to work as-is with no modifications.

* All usage of `Show` where implementations just delegate to another should
  continue to work as-is.

[breaking-change]

Closes #20352

Treemap should be BTreeMap

Rename `FPCategory` to `FpCategory` and `Fp* to `*` in order to adhere to the
naming convention

This is a [breaking-change].

Existing code like this:
```
use std::num::{FPCategory, FPNaN};
```
should be adjusted to this:
```
use std::num::FpCategory as Fp
```

In the following code you can use the constants `Fp::Nan`, `Fp::Normal`, etc.

This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.

All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.

To migrate all crates, add the following to your `Cargo.toml`:

    [dependencies]
    rustc-serialize = "0.1.1"

And then add the following to your crate root:

    extern crate "rustc-serialize" as rustc_serialize;

Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.

[breaking-change]

followed by a semicolon.

This allows code like `vec![1i, 2, 3].len();` to work.

This breaks code that uses macros as statements without putting
semicolons after them, such as:

    fn main() {
        ...
        assert!(a == b)
        assert!(c == d)
        println(...);
    }

It also breaks code that uses macros as items without semicolons:

    local_data_key!(foo)

    fn main() {
        println("hello world")
    }

Add semicolons to fix this code. Those two examples can be fixed as
follows:

    fn main() {
        ...
        assert!(a == b);
        assert!(c == d);
        println(...);
    }

    local_data_key!(foo);

    fn main() {
        println("hello world")
    }

RFC #378.

Closes #18635.

[breaking-change]

Relax some of the bounds on the decoder methods back to FnMut to help accomodate
some more flavorful variants of decoders which may need to run the closure more
than once when it, for example, attempts to find the first successful enum to
decode.

This a breaking change due to the bounds for the trait switching, and clients
will need to update from `FnOnce` to `FnMut` as well as likely making the local
function binding mutable in order to call the function.

[breaking-change]

Fixes #19719.

This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.

A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.

For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.

This breaks code like:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

Change this code to:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    impl Copy for Point2D {}

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

This is the backwards-incompatible part of #13231.

Part of RFC #3.

[breaking-change]

Except for the example code!

JSON doesn't distinguish between integer and float. They are just
numbers. Also, in the current implementation, a fractional number
without the fractional part is encoded without a decimal point.

Thereforce, when the value is decoded, it is first rendered as Json,
either I64 or U64. This reduces type safety, because while the original
intention was to cast the value to float, it can also be casted to
integer.

As a workaround of this problem, this commit makes the encoder always
emit a decimal point even if it is not necessary. If the fractional part
of a float number is zero, ".0" is padded to the end of the result.

[breaking-change]

When an integral value is expected by the user but a fractional value is
found, the current implementation uses std::num::cast() to coerce to an
integer type, losing the fractional part. This behavior is not desirable
because the number loses precision without notice.

This commit makes it raise ExpectedError when such a situation arises.

[breaking-change]

serialize::json::Encoder currently uses f64 to emit any integral type.
This is possibly due to the behavior of JavaScript, which uses f64 to
represent any numeric value.

This leads to a problem that only the integers in the range of [-2^53+1,
2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably
in the current implementation.

RFC 7159 suggests that good interoperability can be achieved if the
range is respected by implementations. However, it also says that
implementations are allowed to set the range of number accepted. And it
seems that the JSON encoders outside of the JavaScript world usually
make use of i64 values.

This commit removes the float preprocessing done in the emit_* methods.
It also increases performance, because transforming f64 into String
costs more than that of an integral type.

Fixes #18319

[breaking-change]