Allow @objc protocols to declare async alternatives

[beccadax]

In #41828, I corrected a longstanding oversight where Swift did not check for conflicting selectors in protocols. Unfortunately, we’ve discovered a situation where we want to permit this. You should be able to declare an @objc protocol in Swift which mimics the behavior of an imported ObjC protocol with an __attribute__((swift_async)) requirement, allowing either a completion handler implementation or an async implementation to satisfy both requirements:

@objc protocol HandleThing {
    @objc(handleThing:completion:)
    func handle(thing: Thing) async

    @available(*, renamed: “handle(thing:)”)    // specifies an async alternative
    @objc(handleThing:completion:)
    func handle(thing: Thing, completion: @escaping () -> Void)
}

This PR suppresses the diagnostic in this situation, and also makes sure that only the completion-handler-based requirement gets printed into the generated header, rather than printing both.

Fixes rdar://94175167.

[beccadax]

@swift-ci please smoke test

[beccadax]

@swift-ci please smoke test

[xymus]

This looks good!

[beccadax]

For those following along at home, I believe that the behavior change addressed in #59743 was caused by us now inserting conflicts into ObjCMethodConflicts when vec.size() >= 1 instead of only when vec.size() == 1. When a method had both completion handler and async variants, vec.size() would start off at 2 and there would be no way for a user-defined conflicting method to ever add an entry to ObjCMethodConflicts.