Introduce a tcx() helper method to cleanup this mess.
Make ty_bare_fn carry an optional def-id indicating whether it is the
type of a fn item or a fn pointer, which are now differentiated.
Introduce coercion from fn item to fn pointer.
Rote changes that don't care to distinguish between a fn pointer and a fn item.
Adjust metadata for new fields and enum variants. Yawn.
Insert FIXME links to issue #19925: fn item types should be zero-sized.
Perform coercions on LHS assignments.
Fix fallout from changes. In cases where stage0 compiler is needed, we
cannot use an `as` expression to coerce, so I used a one-off function
instead (this is a no-op in stage0, but in stage1+ it triggers
coercion from the fn pointer to the fn item type).
Insert coercions to fn pointer types required for the new types
post-unboxed-closure-conversion. This requires a fair amount of
annoying coercions because all the `map` etc types are defined
generically over the `F`, so the automatic coercions don't propagate;
this is compounded by the need to use `let` and not `as` due to
stage0. That said, this pattern is to a large extent temporary and
unusual.
Various simple tests for fn item type vs fn pointer type and for coercions between them.
Change print out to include the path to the fn, a bit ad-hoc for now .
Address nit.
Correct merge failure around imports in `str.rs`.
Tweak region-related error messages that changed slightly due to coercion
changes, and also stop printing semi-useless inference by-products.
auto merge of #19891 : nikomatsakis/rust/unique-fn-types-3, r=nrc

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