[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:
I thought about this with the current `ObservableProperty` too, and tentatively decided against it for two reasons:

 1. Relying upon runtime-heavy features like KVC or KVO seems antiquated and confusing. For example, how do we explain to users that their plain Swift properties won't quite work that way unless you add `dynamic` (and would we want to suggest that anyways)?
 1. The key would have to be a string. There's really no way around this one, that I know of. That really worries me.