libsyntax: abstract most of the deriving boilerplate into a simpler(r) interface.

Pulls out many of the common patterns from the Eq and Clone deriving code (and
invents a few of its own), so that deriving instances are very easy to write
for a certain class of traits. (Basically, those which don't have parameters
and where all methods only take arguments of type `&Self` and return either
`Self` or types with no parameters.)
libcore: combine cmp::Ordering instances in lexical order.
libsyntax: derive Clone, Eq, TotalEq, Ord, TotalOrd with the new generic deriving code.

Closes #4269, #5588 and #5589.
testsuite: add tests for derived Eq, TotalEq, Ord, TotalOrd.
libsyntax: short-circuit on non-matching variants in deriving code.

Allow a deriving instance using the generic code to short-circuit for
any non-matching enum variants (grouping them all into a _ match),
reducing the number of arms required. Use this to speed up the Eq &
TotalEq implementations.
libsyntax: (maybe) fix deriving(TotalOrd) on windows
libsyntax: another fix for deriving on windows.
auto merge of #5640 : dbaupp/rust/syntax-generalise-deriving, r=thestinger

This refactors much of the ast generation required for `deriving` instances into a common interface, so that new instances only need to specify what they do with the actual data, rather than worry about naming function arguments and extracting fields from structs and enum. (This all happens in `generic.rs`. I've tried to make sure it was well commented and explained, since it's a little abstract at points, but I'm sure it's still a little confusing.)

It makes instances like the comparison traits and `Clone` short and easy to write.

Caveats:
- Not surprisingly, this slows the expansion pass (in some cases, dramatically, specifically deriving Ord or TotalOrd on enums with many variants).   However, this shouldn't be too concerning, since in a more realistic case (compiling `core.rc`) the time increased by 0.01s, which isn't worth mentioning. And, it possibly slows type checking very slightly (about 2% worst case), but I'm having trouble measuring it (and I don't understand why this would happen). I think this could be resolved by using traits and encoding it all in the type system so that monomorphisation handles everything, but that would probably be a little tricky to arrange nicely, reduce flexibility and make compiling rustc take longer. (Maybe some judicious use of `#[inline(always)]` would help too; I'll have a bit of a play with it.)
- The abstraction is not currently powerful enough for:
  - `IterBytes`: doesn't support arguments of type other than `&Self`.
  - `Encodable`/`Decodable` (#5090): doesn't support traits with parameters.
  - `Rand` & `FromStr`; doesn't support static functions and arguments of type other than `&Self`.
   - `ToStr`: I don't think it supports returning `~str` yet, but I haven't actually tried.

  (The last 3 are traits that might be nice to have: the derived `ToStr`/`FromStr` could just read/write the same format as `fmt!("%?", x)`, like `Show` and `Read` in Haskell.)
 
  I have ideas to resolve all of these, but I feel like it would essentially be a simpler version of the `mt` & `ty_` parts of `ast.rs`, and I'm not sure if the simplification is worth having 2 copies of similar code.

Also, makes Ord, TotalOrd and TotalEq derivable (closes #4269, #5588 and #5589), although a snapshot is required before they can be used in the rust repo.

If there is anything that is unclear (or incorrect) either here or in the code, I'd like to get it pointed out now, so I can explain/fix it while I'm still intimately familiar with the code.