syntax: pass options to #[deriving] implementations.

For example, in #[deriving(SomeTrait(foo, bar="baz", qux))], the bracketed
data will get passed to the SomeTrait implementation. It supports both the
list notation and the #[deriving(SomeTrait="a literal")] notation.
syntax: allow cmp derived traits to adjust the implementation on normal structs.

Example:

    #[deriving(Eq(test_order(y), ignore(z, w)),
               TotalOrd(reverse(x)))]
    struct Foo {
        x: uint,
        y: uint,
        z: uint,
        w: uint
    }

This allows several things to be controlled:
- `test_order` prioritises certain fields (e.g. the cheapest tests be placed
  first), i.e. y is tested first, and then x. This will not change the result of
  `Eq` & `TotalEq` impls, but can change `Ord` & `TotalOrd`
- `reverse` reverses the result of Ord & TotalOrd comparisons for the given fields
   (so it is as if x = 1 > x = 2 in the example above)
- `ignore` completely removes the fields from the comparison, e.g. `z` and `w` are
   not considered at all for the `Eq` impl of `Foo` above.

Only `Eq` and `Ord` accept `ignore` (since a `Total*` impl ignoring some fields
would not be total), and only `Ord` and `TotalOrd` accept `reverse`. All 4 traits
accept `test_order`.

Any other option, or using a syntax different to `#[deriving(Trait(opt(field1,
field2, ..)))]`, is an error. Using any of these options on an enum, or a tuple or
unit struct is also an error.
doc: document the options able to be passed to #[deriving] for {,Total}{Eq,Ord}
syntax: address reviewer's comments.