Work around #8256, do not fail the task, just return None
libsyntax/ext/deriving/cmp/* was ignored by the build system.
syntax: make #[deriving(TotalOrd)] lazy.

Previously it would call:

  f(sf1.cmp(&of1), f(sf2.cmp(&of2), ...))

(where s/of1 = 'self/other field 1', and f was
std::cmp::lexical_ordering)

This meant that every .cmp subcall got evaluated when calling a derived
TotalOrd.cmp.

This corrects this to use

   let test = sf1.cmp(&of1);
   if test == Equal {
      let test = sf2.cmp(&of2);
      if test == Equal {
        // ...
      } else {
        test
      }
   } else {
     test
   }

This gives a lexical ordering by short-circuiting on the first comparison
that is not Equal.
std: implement Total{Ord,Eq} for pointers.
Open files in binary mode. Closes #3948
std: Use correct lifetime parameter on str::raw::slice_bytes

fn slice_bytes is marked unsafe since it allows violating the valid
string encoding property; but the function did also allow extending the
lifetime of the slice by mistake, since it's returning `&str`.

Use the annotation `slice_bytes<'a>(&'a str, ...) -> &'a str` so
that all uses of slice_bytes are region checked correctly.
Make node_id_to_str print more useful info in some cases. Closes #2410.
Fix an unused variable warning and clean up some dead code/names.
Warn when using -o option on libraries. Closes #6554.
Get rid of some NOTEs.
Improve debug spew in _match.
Use TreeMap's ord implementation for Json

Closes #4430
auto merge of #8298 : darkf/rust/fix-3948, r=pcwalton
(cleanup) Uncomment an assertion that now holds.
Lazily initialize 'leaf node' taskgroups for unlinked spawns, for an apparent 11% speedup.
auto merge of #8288 : Kimundi/rust/opteitres4, r=brson

This is an alternative version to https://github.com/mozilla/rust/pull/8268, where instead of transitioning to `get()` completely, I transitioned to `unwrap()` completely.

My reasoning for also opening this PR is that having two different functions with identical behavior on a common datatype is bad for consistency and confusing for users, and should be solved as soon as possible. The fact that apparently half the code uses `get()`, and the other half `unwrap()` only makes it worse.

If the final naming decision ends up different, there needs to be a big renaming anyway, but until then it should at least be consistent.

---

- Made naming schemes consistent between Option, Result and Either
- Lifted the quality of the either and result module to that of option
- Changed Options Add implementation to work like the maybe Monad (return None if any of the inputs is None)  
  See https://github.com/mozilla/rust/issues/6002, especially my last comment.
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead  
  See also https://github.com/mozilla/rust/issues/7887.

Todo: 

Adding testcases for all function in the three modules. Even without the few functions I added, the coverage wasn't complete to begin with. But I'd rather do that as a follow up PR, I've touched to much code here already, need to go through them again later.
Re-enable rusti tests
std: Add .consume_iter() for Option, to make it reusable

Let Option be a base for a widely useful one- or zero- item iterator.
Refactor OptionIterator to support any generic element type, so the same
iterator impl can be used for both &T, &mut T and T iterators.
std: Convert Result to use external iterators

convert iter() and iter_err() for Result. Use OptionIterator.
std: Remove unused trait bound in Result::map