This is a continuation of the work done in #13184 to make struct fields private
by default. This commit finishes RFC 4 by making all tuple structs have private
fields by default. Note that enum variants are not affected.

A tuple struct having a private field means that it cannot be matched on in a
pattern match (both refutable and irrefutable), and it also cannot have a value
specified to be constructed. Similarly to private fields, switching the type of
a private field in a tuple struct should be able to be done in a backwards
compatible way.

The one snag that I ran into which wasn't mentioned in the RFC is that this
commit also forbids taking the value of a tuple struct constructor. For example,
this code now fails to compile:

    mod a {
        pub struct A(int);
    }

    let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private

Although no fields are bound in this example, it exposes implementation details
through the type itself. For this reason, taking the value of a struct
constructor with private fields is forbidden (outside the containing module).

RFC: 0004-private-fields

This is an implementation of a portion of [RFC #4](https://github.com/rust-lang/rfcs/blob/master/active/0004-private-fields.md). This PR makes named struct fields private by default (as opposed to inherited by default).

The only real meaty change is the first commit to `rustc`, all other commits are just fallout of that change.

Summary of changes made:

* Named fields are private by default *everywhere*
* The `priv` keyword is now default-deny on named fields (done in a "lint" pass in privacy)

Changes yet to be done (before the RFC is closed)

* Change tuple structs to have private fields by default
* Remove `priv` enum variants
* Make `priv` a reserved keyword

This commit switches privacy's checking of fields to have *all* fields be
private by default. This does not yet change tuple structs, this only affects
structs with named fields. The fallout of this change will follow shortly.

RFC: 0004-private-fields

cc #8122
Closes #11809

The implementation of `Encodable<E, S>` for `Json` doesn't need to assume `S` to be `IoError`, only the default encoders for `Json` are depend on it. So this can be parametrize to increase flexiblity. If not, types that implement `Encoder<E>` where `E` is not `IoError` can't be worked with `Json`.

These were only free functions on `~[T]` because taking self by-value
used to be broken.

Mac can't actually build our source tarballs because it's `tar`
command doesn't support the --exclude-vcs flag. This is just
a workaround to make our mac nightlies work (we get our source
tarballs from the linux bot).

Correct printing (sort, new lines), reading on stdin.

These were only free functions on `~[T]` because taking self by-value
used to be broken.

When running `make install` we are touching these files that can't
then be removed later.