Implement unique types per fn item, rather than having all fn items have fn pointer type

This is part of the coercion RFC but also makes sense given unboxed closures. The idea is that every fn item has its own type. This type can be coerced to a fn pointer but is not a fn pointer. This PR does almost all the end-user visible changes, but leaves one thing undone: the representation of an instance of a "fn item type" is still a fn pointer at runtime. A later PR will have to change them to zero-sized values (I'll open an isssue on this).

This is a [breaking-change]. In general, the coercion rules ensure that code which used to take a `fn()` type continus to work, but there are some patterns that need to be changed to insert explicit coercions.

Example 1:

If/match arms sometimes require explicit types now:

```rust
fn foo(x: int) -> int { x }
fn bar(x: int) -> int { x + 1}

// old:
// let x = if some_cond { foo } else { bar };

// new:
let x: fn(int) -> int = if some_cond { foo } else { bar } // coerce to a fn pointer
```

Example 2: 

Generic functions are another place where coercions often fail to trigger. Example:

```rust
fn foo(x: int) -> int { x }

fn optional() -> Option<fn(int) -> int> {
    // Old:
    // Some(foo) // here the type argument on `Some` is inferred to be the fn item type

    // New:
    Some(foo as fn(int) -> int)
}
```

This one may or may not get fixed going forward; inserting coercions in cases like these involves subtle changes to program semantics that may not be appropriate.

r? @nick29581 
Yes, I plan to open a FIXME issue once review is done. Basically I left the trans representation of a "fn item type" as a pointer, but it should eventually be something zero-sized -- all the relevant information is carried in the type itself.