[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:
> @andymatuschak What do you think about the evidence parameters required right now for certain operators? I think those are a significant impediment to novices as well, and switching to free functions solves that problem.

Totally agreed. I hadn't seen them. This really changes the cost–benefit analysis I was performing. I don't have a better idea for resolving those. Yuck. Not happy with the operator, but it's a clever solution, and those evidence arguments have gotta go. Carry on.

> I have an example of where the “implementation detail” matters, too. Many users implement custom signal operators, and I applaud that (partly because it helps keep the official API surface area small).

> If a user were to add their own operator to this API, they would normally have to define it twice. If they can instead define it as a free function, and we automatically lift it for them, that's pretty awesome.

I don't think this argument's sufficient for the operator: we could tell people "a common pattern for doing this is to define a free function and call it in both places." Not painful enough in this uncommon case to merit making such a common case harder.