Fix to -rac_signalForSelector: properly implement -respondsToSelector: for optional method from a protocol

[ikesyo]

If an instance is callded -rac_signalForSelector:fromProtocol: for a certain protocol's optional method (its class doesn't implement that), the instance should respond to the selector. Then, another instance of the same class that is called -rac_signalForSelector: with other selectors, but not called with the optional method selector, should not respond to the selector.

Originally, class_addMethod() makes all instances of the class respondable to the optional method selector. It leads to a crash from -doesNotRecognizeSelector: at RACSwizzleForwardInvocation in following pattern:

if ([anotherInstance respondsToSelector:@selector(someOptionalMethod:)]) {
    // The instance responds to the selector, but it doesn't have a signal for the selector.
    // So, `RACForwardInvocation()` returns NO.
    [anotherInstance someOptionalMethod:@1];
}

[jspahrsummers]

Associated objects are somewhat expensive. We might want to save this check until we've verified that the method exists (below).

[jspahrsummers]

This fix makes sense to me. Thanks! ✨

@kastiglione Do you want to take a look too?

[ikesyo]

🚀

[kastiglione]

What was the reason for moving the call to originalRespondsToSelector into this condition? Is there a case where hasMessageForwardingImplementation is false, yet an associated subject will exist?

[ikesyo]

@kastiglione Thanks to point out it! It's just my misunderstanding / too much thinking. I made it simple.

[kastiglione]

@jspahrsummers Just the one question to @ikesyo.

Thanks @ikesyo, good fix.

[ikesyo]

@jspahrsummers @kastiglione I made it more cleaner / simpler. Re-ready for review.

[kastiglione]

[jspahrsummers]

💎💎💎💎💎💎💎💎💎💎🚢💎💎💎💎💎💎💎💎💎
💎💎💎💎💎💎💎💎💎🚢🚢🚢💎💎💎💎💎💎💎💎
💎💎💎💎💎💎💎💎🚢💎🚢💎🚢💎💎💎💎💎💎💎
💎💎💎💎💎💎💎🚢💎💎🚢💎💎🚢💎💎💎💎💎💎
💎💎💎💎💎💎🚢💎💎💎🚢💎💎💎🚢💎💎💎💎💎
💎💎💎💎💎🚢💎💎💎💎🚢💎💎💎💎🚢💎💎💎💎
💎💎💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎💎
💎🚢🚢💎💎💎💎💎💎💎🚢💎💎💎💎💎💎🚢🚢💎
💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎
💎💎💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎💎