RACQueuedSignalGenerator, class constructors instead of initializers

`RACQueuedSignalGenerator` can be used to enforce mutual exclusion over a set of generated signals.

I thought of this while trying to replace a `RACCommand` under 3.0, because there's otherwise no convenient way to serialize an operation _that requires input_ (`-shareWhileActive` can be used if there's no input). And although serialization requires some state, this takes it out of the hands of the caller.

I decided against throwing an error—like `RACCommand` did—because that feels rather imperative. If subscribing twice concurrently is erroneous, we'd be implying that the caller should have knowledge about other possible callers and whether the generator is currently "in use."

On the other hand, simply enqueuing/delaying the request is completely consistent with asynchronous signals. Most callers won't care how long their operation takes, and there are operators like `-timeout:` if they do.

_See d39c2b254266f8f5568cef3e5d9918da7490c7fe for an explanation of the constructor changes I snuck in._

@jonsterling @paulcbetts