That does not work if there is a resilient class in the hiearchy from a
different module than the testable imported one. Rather treat an
internal but testable imported class as having resilient metadata.
The scenario that does not work assuming we can build a fragile layout
is the following.
FrameworkA is resilient and defines a public class `Base` with a stored field.
FrameworkB is resilient and defines an internal class `Sub` that inherits from
the class `Base` in FrameworkA and adds some fields. FrameworkB is compiled
with enable-testing.
The test case testable imports FrameworkB and accesses a field in the
internal class `Base` from FrameworkB. The test case only has access to
FrameworkA's public swiftinterface file and therefore does not know
`Base`'s layout. The layout computation for `Sub` cannot take the field
from `Base` into account and things fail silently.
rdar://103323275
