If the callee is a non-generic thunk which calls a (not inlinable) generic function in the defining module,
it's more efficient to not devirtualize, but call the non-generic thunk - even though it's done through the witness table.
Example:
```
protocol P {
func f(x: [Int]) // not generic
}
struct S: P {
func f(x: some RandomAccessCollection<Int>) { ... } // generic
}
```
In the defining module, the generic conformance can be fully specialized (which is not possible in the client module, because it's not inlinable).
rdar://102623022
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
It's not clear whether we'll actually need this feature in the long
run, but we certainly need it now because non-@usableFromInline
members can (currently) satisfy public requirements when a
@usableFromInline internal type conforms to a public protocol. In
these cases, we'll treat the witnesses as present but opaque, and
clients will perform dynamic dispatch when using them even when
a generic function gets specialized.
With this, we're able to generate a textual interface for the standard
library, compile it back to a swiftmodule, and use it to build a Hello
World program!
