[RFC] Replace ColdSignal and HotSignal with SignalTemplate and Signal (a.k.a. Round and Around We Go)

After the long discussion in #1650, I invited @NachoSoto, @andymatuschak, and @kastiglione to talk more in-depth about the Swift APIs, and specifically where they need improvement.

We had a really, really great brainstorming session, and this is the result. The good news is that we all feel pretty good about this direction, and the bad news is that everything is getting rewritten again. :trollface:

The important bits are documented on the types themselves, but here’s the handy Quick Start guide of the proposed changes:

1. `HotSignal<T>` will be replaced by `Signal<T>`. Besides the name change, these signals can now send `Error` and `Completed` events. This avoids a lot of the lifecycle weirdness that has come up with a value-only `HotSignal`.
1. `ColdSignal<T>` will be replaced by `SignalTemplate<T>`. As the name implies, a signal template creates `Signal`s (via the `start` method). You can kind of think of the relationship as `SignalTemplate : Signal :: RACSignal : subscription`, or `SignalTemplate : Signal :: class : instance`.
1. Most of the basic operators are written in terms of `Signal`, but can be lifted to apply to `SignalTemplate` instead.
1. Operators that benefit from “cold” semantics, like `retry` and `repeat`, are written in terms of `SignalTemplate`.

The advantages here are:

* The relationship between “hot” and “cold” signals is now much more explicit and well-defined. A “cold” signal (a template) creates “hot” signals, each of which represents a “subscription” (in RAC 2.x terms).
* Many operators only have to be written once, in terms of `Signal`, and can be lifted to the `SignalTemplate` level.
* The semantics and/or difficulties of converting between “hot” and “cold” are more obvious, I think. You don’t need to swap between them on the fly, because they mean different things.
* Signal lifetime is no longer implicit for “cold” signals. The lifetime of a template’s event stream is defined entirely by the signals you create from that template.

I’ll also make some notes in the changes below, to explain more specific things. Please leave feedback if you have it! :bow:
This was not specifically part of the discussion that I had with @NachoSoto, @kastiglione, and @andymatuschak, but rather occurred to me while I was sketching the interfaces.

Syntax pros/cons aside, the really huge benefit here is that `|>` can be used to _automatically_ lift `Signal` operators to the `SignalTemplate` level, using the overloads in `SignalTemplate.swift`.

This means we have a uniform way of describing `Signal` transformations, no matter which level you’re working at, and we don't have to implement a bunch of duplicate stub operators on `SignalTemplate` to get that.