This PR addresses TODOs from #8241.
- It supports merging for layout constraints, e.g., if both a _Trivial constraint and a _Trivial(64) constraint appear on a type parameter, we keep only _Trivial(64) as a more specific layout constraint. We do a similar thing for ref-counted/native-ref-counted. The overall idea is to keep the more specific of two compatible layout constraints.
- The presence of a superclass constraint implies a layout constraint, e.g., a superclass constraint implies _Class or _NativeClass
- Add support for _Class and _NativeClass layout constraints, which are supposed to represent T: Superclass and P: class constraints in the future.
- Use the re-factoring to also reduce the number of dynamic allocations when creating layout constraints. Simple non-parametrized layout constraints are now represented as statically allocated singletons (static members of LayoutConstraintInfo).
This biggest change is:
- LayoutConstraintInfo is now a FoldingSetNode, which allows for proper canonicalization of LayoutConstraints. This is important for the correctness of type comparisons if types contain layout constraints.
No functionality changes from the client's point of view.
The new `@_specialize` attribute has a syntax like this:
```swift
@_specialize(exported: true, kind: full, where K == Int, V == Int)
@_specialize(exported: false, kind: partial, where K: _Trivial64)
func dictFunction<K, V>(dict: Dictionary<K, V>) {
}
```
If `exported` is set, the corresponding specialization would have a public visibility and can be used by clients.
If `exported` is omitted, it's value is assumed to be `false`.
If `kind` is `full` it means a full specialization.
If `kind` is `partial` it means a partial specialization.
If `kind` is omitted, its value is assumed to be `full`.
