Issue Description:

When working with Objective-C frameworks (including some of the ones included with the OS), it's not uncommon to find APIs that look like this:

- (id)foo:(Protocol *)proto;

which take a protocol, and return a proxy object that conforms to the protocol. In Objective-C, these aren't bad to use, but in Swift the above gets interpreted as:

func foo(_ proto: Protocol) -> Any

which requires us to jump through some type-checking hoops before we'll be able to use the proxy in any meaningful way.

It might be helpful to make a wrapper around such APIs using Generics, which could potentially make these APIs more convenient to use from Swift. Unfortunately, I can't find any way to explicitly mention that a conforming protocol metatype is desired (`<P: Super.Type>` results in 'error: inheritance from non-protocol, non-class type 'Super.Type''; please accept my apologies if there's some brain-dead simple way to specify this that I've overlooked), but we can generically require any type conforming to the protocol, and then simply document that the function should only passed protocol metatypes, like so:

@objc protocol Super {}
@objc protocol Sub: Super {}

// Only pass a protocol to this!
func bar<P: Super>(proto: P.Type) {}

bar(proto: Sub.self)

Interestingly, this will compile if the protocols do not have the `@objc` attribute on them, but will throw `error: in argument type 'Sub.Protocol', 'Sub' does not conform to expected type 'Super'` if they are pure-Swift protocols.

Anyway, we now have a function to which we can pass arbitrary Objective-C protocols (that conform to `Super`). Unfortunately, the Objective-C bridge does not recognize this parameter in the way that it would an explicitly specified protocol metatype:

func bar<P: Super>(proto: P.Type) {
    // compiles, runs, works:
    let proxy1 = foo(Sub.self)

    // error: cannot convert value of type 'P.Type' to expected argument type 'Protocol'
    let proxy2 = foo(proto)
}

Moreover, most of the methods we'd use to manually invoke the Objective-C bridge cause crashes at runtime. For example, the standard cast to `AnyObject` behaves thus:

func bar<P: Super>(proto: P.Type) {
    // <Protocol: 0x103a82100>
    print(Sub.self as AnyObject)
        
    // Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of
    // incompatible type!"), function cast, file
    // /path/to/swift/llvm/include/llvm/Support/Casting.h, line 255
    //
    // (If the compiler's been built in Release mode, you just get
    // 'Terminated due to signal: SEGMENTATION FAULT (11)')
    print(proto as AnyObject)
}

What if we explicitly cast to `Super`, since we know whatever we have should conform to that? Well, this gets a bit weird depending on which cast operator you use:

func bar1<P: Super>(proto: P.Type) {
    let intermediate = proto as Super.Type
    print(intermediate as AnyObject)  // crash!
}

func bar2<P: Super>(proto: P.Type) {
    let intermediate = proto as! Super.Type
    print(intermediate as AnyObject) // crash!
}

func bar3<P: Super>(proto: P.Type) {
    // warning: conditional cast from 'P.Type' to 'Super.Type' always succeeds
    let intermediate = proto as? Super.Type

    print(intermediate as AnyObject) // <Protocol: 0x10500d100>
}

The `bar3` method above actually works as intended ( ! ) , although it causes a warning that can't be eliminated. The warning suggests using `as` instead; of course, if we do that, the cast to AnyObject will crash.

So what's causing this? It turns out that the compiler generates different assembly calls to do the actual bridging depending on the operator used and whether the type is generic or not, which I've illustrated by adding comments in the code below.

func bar<P: Super>(proto: P.Type) {
    // callq  0x100001a60; type metadata accessor for crasher.Sub
    // movq   %rax, -0x18(%rbp)
    // movq   -0x20(%rbp), %rdi
    // movq   %rdx, -0x28(%rbp)
    // callq  0x100001d80; type metadata accessor for crasher.Sub.Protocol
    // leaq   -0x18(%rbp), %rdi
    // movq   %rax, %rsi
    // movq   %rdx, -0x30(%rbp)
    // callq  0x100001df2; symbol stub for: Swift._bridgeAnythingToObjectiveC<A>(A) -> Swift.AnyObject
    // (works)
    let p1 = Sub.self as AnyObject

    // callq  0x100001e28; symbol stub for: swift_getObjCClassFromMetadata  (crashes)
    let p2 = proto as AnyObject

    // callq  0x100001c80; type metadata accessor for Swift.Optional<crasher.Super.Type>
    // leaq   -0x20(%rbp), %r13
    // movq   %rax, %rdi
    // movq   %rdx, -0x28(%rbp)
    // callq  0x100001dd0; symbol stub for: Swift.Optional._bridgeToObjectiveC() -> Swift.AnyObject (works)
    let i3 = proto as? Super.Type
    let p3 = i3 as AnyObject

    // callq  0x100001e28; symbol stub for: swift_getObjCClassFromMetadata (crashes)
    let i4 = proto as Super.Type // or as!; same result
    let p3 = i4 as AnyObject
}

From this, it appears that with the generic type, as well as with the generic type cast using `as` or `as!`, the compiler assumes that the generic type will always be a concrete class metatype. This turns out to be a bad assumption, since the generic parameter may be a protocol metatype.

I hope you've found this report helpful.