More ways to merge HotSignals; Update to carthage 0.4

Addresses #1647.

In terms of new functionality, this PR adds a `merge` overload to `ColdSignal` which merges a `ColdSignal` of `HotSignal`s, as well as the `merge(SequenceType)` class method and `mergeWith(HotSignal)` instance method to `HotSignal`, which are essentially conveniences for the former. And I added some tests to check that these work.

I've also updated the project to use the new Carthage 0.4 directory structure (mostly because I have 0.4 installed and I needed to build the project ¯\\\_(ツ)\_/¯ ). But this is all confined to 1 commit so I can easily revert it if we don't want to update yet.

I have a few small things that I'm unsure about here: 
- Whether the `merge(SequenceType)` class method should be considered a "Convenience constructor" or a "Method for combining multiple signals". I put it in the latter extension, but I could see the case being made for either.
- If `ColdSignal`'s `mergeMap() -> ColdSignal` would need to be changed now that there is an overload that returns a `HotSignal`. I suspect it will be, but I'm not sure what the best solution is.
- I made my best guess for the generics mumbo-jumbo in HotSignal.swift:573 but it doesn't feel exactly right.

And of course please do let me know if anything else doesn't look right!
Sorry, to clarify, I _don't_ think there's anything wrong with embedding HotSignals in ColdSignals, or vice-versa. However, I do think it can make things harder if you don't know what you're doing (because there are few ways to combine the two types), and I anticipate a lot of crazy questions that come from mixing the two in weird ways. :stuck_out_tongue_closed_eyes: 

Another way to think about this is: given a method that RAC provides, a subset of users will try to make their types match so they can use it, _even if that doesn't make sense_ for what they're doing. I don't want users thinking that they _must_ create a `ColdSignal<HotSignal<T>>` in order to perform the merge operation.

So my concern is really coming from the perspective of, “What should the framework encourage?” or perhaps, “What should we guide users toward?” In that regard, I think this method's signature might be more confusing than helpful.