Result::or : avoid over-specializing the type

Changes .or() so that it can return a Result with a different E type
than the one it is called on.

Essentially:

    fn or(self, res: Result<T, E>) -> Result<T, E>

becomes

    fn or<F>(self, res: Result<T, F>) -> Result<T, F>

This brings `or` in line with the existing `and` and `or_else` member
types.

This is a
[breaking-change]
Due to some code needing additional type annotations.

Author: codyps

src/libcore/result.rs

@@ -641,9 +641,9 @@ impl<T, E> Result<T, E> {
     /// ```
     #[inline]
     #[stable(feature = "rust1", since = "1.0.0")]
-    pub fn or(self, res: Result<T, E>) -> Result<T, E> {
+    pub fn or<F>(self, res: Result<T, F>) -> Result<T, F> {
         match self {
-            Ok(_) => self,
+            Ok(v) => Ok(v),
             Err(_) => res,
         }
     }

src/libcoretest/result.rs

@@ -36,10 +36,10 @@ pub fn test_and_then() {
 
 #[test]
 pub fn test_or() {
-    assert_eq!(op1().or(Ok(667)).unwrap(), 666);
+    assert_eq!(op1().or(Ok::<_, &'static str>(667)).unwrap(), 666);
     assert_eq!(op1().or(Err("bad")).unwrap(), 666);
 
-    assert_eq!(op2().or(Ok(667)).unwrap(), 667);
+    assert_eq!(op2().or(Ok::<_, &'static str>(667)).unwrap(), 667);
     assert_eq!(op2().or(Err("bad")).unwrap_err(), "bad");
 }