Add UICollectionViewCell.rac_prepareForReuseSignal
- Removed UICollectionViewCell+RACSignalSupport.h from ReactiveCocoa.h because this category applies to iOS >= 6.0 and the apparent minimum version of iOS supported by ReactiveCocoa is iOS >= 5.0.
- Adjusted UICollectionViewCellRACSupportSpec.m to account for known cases where prepareForReuse is never called in some simulator/device configurations.
Modifications as requested by jspahrsummers:

- Marked UICollectionViewCell+RACSignalSupport.h as a public header.
- Adjusted indentation in UICollectionViewCell+RACSignalSupport.m.
- Changed to use dot syntax.
- Use NSStringFromClass instead of [Class description].
- Clarified a confusing comment.
- Simplified the expectations around invocationCount.
Minor style tweaks
Merge pull request #846
Added passWhen:sendError:
Add test that `-[RACMulticastConnection connect]` isn’t racy
Fix race condition when connecting to a multicast connection

Every connect caller gets the disposable now
Add missing import
Added try: & tryMap: Removed passWhen
Test case names for try: tryMap:
Remove the lock when connecting

Using an atomic compare and swap we can determine whether the caller should connect to source signal.
Use a serial disposable created at initialisation time so that connection is non blocking and connection can always return a disposable to callers, even if we aren’t connected yet.
Simplify the race condition test

This is the test from @kastiglione with the addition of a semaphore. Using the semaphore we ensure that the disposable is nil because of the bug we’re testing rather than nil because the block enqueued to the scheduler hasn’t run yet.
Style changes & Comparison against value rather than error
tryMap checks for nil return and error set byref
Documentation wording
Move +error: behavior into a private subclass
Move +empty behavior into RACEmptySignal
Move +return: behavior into RACReturnSignal
Move +createSignal: behavior into RACDynamicSignal

This required -subscribe: to be reimplemented from scratch in
RACSubject, but this actually turns out to be a good thing.

Many of the +createSignal: behaviors (like global refcounting) don't
apply to a persistent subject.