swift234

As promised, split up struct_add_remove_conformances library evolution test

We now test four setups, with the four {before, after}^2 runs of each:

a) Client adds conformance -vs- library adds public conformance -- fixed-layout struct
b) Client adds conformance -vs- library removes internal conformance -- fixed-layout struct
c) Client adds conformance -vs- library adds public conformance -- resilient struct
d) Client adds conformance -vs- library removes internal conformance -- resilient struct

The first two pass, but a) requires a hack to ensure we don't
directly reference conformance table, otherwise the 'after_before'
version doesn't link. I think the right idea here is to weakly
reference conformance tables where the deployment target is
lower than the availability of the conformance.

The second two are XFAIL'd until protocol conformance tables can
reference resilient types from other modules. This requires emitting
indirect metadata symbols, since the client doesn't know if the
resilient type's metadata is direct or a template, and the
conformance table cannot use the metadata accessor either.

These tests will also become important if we decide to revisit
synthesized accessors, and make them lazy again for structs.