[RFC] Replace ColdSignal and HotSignal with SignalTemplate and Signal

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 something like:
 * `SignalTemplate : Signal :: RACSignal : subscription`
 * `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 now consistent, and completely defined by the event stream. Templates don’t do anything special—they really are just value types, and don’t encode any information about lifetime.

I’ll also make some notes in the changes below, to explain more specific things. Please leave feedback if you have it! :bow:
Both here and in the updated `Action`, I find the term Plan to be an overstatement, relative semantics of the signal being produced here. Does the term Plan optimize for the aggregate, at the cost of making the more atomic pieces sound more complex? Playing my own devil's advocate, maybe that's beneficial in preventing assumptions about how the sausage is made. It would be nice if we could get a term that can be used for both large and small.

What about `Definition`? Or `Originator` which sounds a lot like `Generator`? Though I'm not sure if "originators" pass the "will it transform" test.