Add composition and subst methods to =:= and <:<

Both scalaz.Leibniz and scalaz.Liskov have useful methods which are not
present in Predef.

https://github.com/scalaz/scalaz/blob/series/7.2.x/core/src/main/scala/scalaz/Leibniz.scala

https://github.com/scalaz/scalaz/blob/series/7.2.x/core/src/main/scala/scalaz/Liskov.scala

I don't see a reason why some of the methods should not be present in
scala-library itself, other than the implementations of these methods
have to be done carefully, since Predef uses the singleton trick. You
can read how scalaz makes a different trade-off on the Typelevel blog:

http://typelevel.org/blog/2014/07/06/singleton_instance_trick_unsafe.html

This commit adds the following:

* <:<#compose
* <:<#andThen
* <:<#subst

* =:=#symm
* =:=#compose
* =:=#andThen
* =:=#subst

This means equality is now an equivalence relation:

* Reflexivity (already existed)
* Symmetry
* Transitivity

I find these very useful when trying to do proofs of equality in Scala.

---

Carefully reviewing this code is important, all implementations are casts.

@djspiewak

@S11001001
Wouldn't this be more useful as implicit machinery?  It's important to realize that `compose` and `andThen` are *both* overloading.  Thanks to the magic™ of subtyping, it's going to be very easy to accidentally get the compiler to infer a less-specific type and find yourself not actually dispatching to either of these methods.  This is not a problem in and of itself, because I'm pretty sure that the `compose` and `andThen` functions inherited from `Function1` will work correctly, they just won't return specific types.  Still thought it was worth mentioning.

What I mean by implicit machinery though is the following judgments:

```scala
object <:< {
  implicit compose[A, B, C](implicit ev1: A <:< B, ev2: B <:< C): A <:< C = singleton_<:<.asInstanceOf[A, C]
  // ...
}
```

This seems like it would be more useful than forcing explicit combinators.