Refactoring in support of higher-ranked traitbounds

[nikomatsakis]

Various miscellaneous changes pushing towards HRTB support:

1. Update parser and adjust ast to support for<'a,'b> syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0).
2. Refactor TyTrait representation to include a TraitRef.
3. Purge once_fns feature gate and once keyword.

r? @pcwalton

This is a [breaking-change]:

• The once_fns feature is now officially deprecated. Rewrite using normal closures or unboxed closures.
• The new for-based syntax now issues warnings (but not yet errors):
  • fn<'a>(T) -> U becomes for<'a> fn(T) -> U
  • <'a> |T| -> U becomes for<'a> |T| -> U

[rust-highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[pcwalton]

nit: weird indentation

[pcwalton]

r=me with the nit

[nikomatsakis]

@pcwalton added one more commit, 9be076d, which purges once_fns

[nikomatsakis]

rebased, merged a bit

[pcwalton]

r=me

[pnkfelix]

@nikomatsakis I only noticed now that rust-lang/rfcs#387 only discusses changing the syntax for fn types, but not for fn definitions themselves.

Concrete example:

fn bar1(g: fn<'a>(x: &'a int) -> &'a int) { g(&3i); }
//           ^~~~
//
// Definition of `bar1` now causes rustc to issue a deprecation warning.

fn bar2(g: for<'a> fn(x: &'a int) -> &'a int) { g(&3i); }
//         ^~~~~~~
//
// You need to use this syntax instead.

// ... BUT ...

fn foo1<'a>(x: &'a int) -> &'a int { x }
//     ^~~~
// This is the only syntax accepted for fn definition forms...

for<'a> fn foo2(x: &'a int) -> &'a int { x } /*
^~~~~~~                                       *
                                              *
...because this syntax is rejected by rustc.  *
                                              */

Is this a problem, in terms of introducing (unnecessary?) deviation between the type and term forms?

[pnkfelix]

( adding reference to the HRTB tracking issue: #18639 )