Issue Description:

import Foundation
class C<T: NSObject> { // note: requirement specified as 'T' : 'NSObject' [with T = NSObject & P]
    var t: T?
}
protocol P {}
typealias TA = C<NSObject & P> // error: 'C' requires that 'NSObject & P' inherit from 'NSObject'

The diagnostic here is less than ideal. One might think "why doesn't the type NSObject & P inherit from NSObject, the dynamic type must be a subclass of NSObject, right?".

We already have a special-case diagnostic for AnyObject in this respect:

class C<T: AnyObject> {
    var t: T?
}
protocol P {}
typealias TA = C<AnyObject & P> // error: 'C' requires that 'AnyObject & P' be a class type 

The diagnostic for the first case should also be changed to be clearer.

I suggest that both these diagnostics be made a bit more verbose.

> "error: 'C' requires that the generic parameter 'T' be a class type, but 'NSObject & P' is a protocol composition type"

(and similarly for the AnyObject case)

The reason this is not permitted is (paraphrasing Slava slightly):

> NSObject & P is a protocol type, not a concrete type. It would introduce soundness issues if we allowed this. For example, imagine if C called an initializer on T. It would not be able to do that at runtime if T was bound to NSObject & P, since there’s no concrete class type to construct.

It would be good to explain this in a small educational note.