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!
Although there's nothing inherently wrong with it, I'm wary of adding an operator that nests hot signals in cold signals (or vice-versa)—mostly because I think it might encourage weird antipatterns on the part of consumers.

Since this could be implemented in terms of `HotSignal.pipe()` and `merge()` pretty easily, could we leave it out?