Enable constrained existential types in protocol compositions

[rnapier]

Description

If a protocol with a primary associated type (such as RangeExpression) is combined using & with another protocol (such as Sendable), it cannot directly be wrapped with any. It can, however, be wrapped with an intermediate typealias.

Steps to reproduce

struct Period: Sendable {
    // Fails:
    // Non-protocol, non-class type 'RangeExpression<Int>' cannot be used within a protocol-constrained type
    var monthsBad: any RangeExpression<Int> & Sendable

    // Succeeds:
    typealias IntRangeSendable = RangeExpression<Int> & Sendable
    var monthsGood: any IntRangeSendable
}

Expected behavior

Both of these should be identical and compile. However, only the second is allowed. The following similar cases are also all allowed:

any CustomStringConvertible & Sendable // non-associated type
any Equatable & Sendable // associated type, but not primary
any RangeExpression & Sendable // primary associated type, but not specified

Environment
swift-driver version: 1.75.1 Apple Swift version 5.8 (swiftlang-5.8.0.117.11 clang-1403.0.22.8.60)
Target: arm64-apple-macosx13.0

Xcode 14.3
Build version 14E5197f

Target: macOS 13.2.1

[AnthonyLatsis]

More self-contained:

protocol P<A> {
  associatedtype A
}
protocol Q {}

do {
  let _: any Q & P<Int>
}

Looks like type resolution is not expecting parameterized protocol types in a composition when the composition is an existential constraint.

[slavapestov]

The restriction here is artificial, we should just remove it.

[vmanot]

Curious about the status of this issue, just ran into it again today.