-replayLazily behavior changes, -autoconnect refactoring

`-replayLazily` no longer uses `-autoconnect`, since it may lead to surprising behavior that's inconsistent with the other `-replay…` operators. Instead, it'll remain subscribed to the underlying signal until completion.

I was going to remove `-autoconnect` after discussion in #757, but ultimately decided against it. In its current incarnation, it's roughly equivalent to Rx's [RefCount](http://msdn.microsoft.com/en-us/library/hh211664%28v=vs.103%29.aspx) operator, and it's hard to replicate that behavior by hand.

In response to @kastiglione's questions:

> 1. Should `-autoconnect` assert that its `disposable` is not disposed? Would there be a use case where subscribing to an autoconnected signal, whose internal connection subscription has previously been disposed?

A multicasted replay subject actually provides a great example here. Because `-autoconnect` guarantees that the subscription will occur immediately, the input signal can be completely replayed even after the connection has been disposed.

> 2. Could `-autoconnect` instead add the connection's `disposable` to the connection's own `rac_deallocDisposable`? That way the connection stays live and usable as long as there is a reference to an autoconnected signal.

Not entirely sure what you're proposing here. What exactly would be the lifetime, and why would this be superior?

> It appears autoconnected signals cause a slightly shorter "usable" lifetime on the connection's `signal`. Instead of living one run loop like normal signals, autoconnected signals break the internal subscription immediately when there are no subscribers.

This is consistent with the semantics of disposal. We're really talking about terminating a _cold_ subscription, which would work the same way on a plain signal too. The signal would continue to _exist_, but any side effects associated with the subscription will be terminated.