[ownership] Make whether or not we serialize in OSSA form based off of a flag instead of off of whether or not we are processing the stdlib.

[gottesmm]

I added a change to CMake so that the stdlib still gets the option passed in so
should be NFC.

I also fixed a small mistake where some optimizations that we intended to run early when optimized ossa was being serialized were turned off. Luckily there is no difference (the opts would have just run on non-ossa SIL and thus would have been a no-op)... but turning these on are important since we found it made a difference in a benchmark that regressed.

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test

[atrick]

Isn't this orthogonal to -O/-Onone?

Doesn't this affect deserialization too, in the sense that imported modules need to be OSSA?

If both those answers are yes, then it should be called '-enable-ossa-modules', which would be an option that users could understand and basically the end-goal for this round of OSSA migration.

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - ba6ee783e5ff7a0bce0d9579261d5d79c962bcdc

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - ba6ee783e5ff7a0bce0d9579261d5d79c962bcdc

[gottesmm]

@atrick it isn't orthogonal to -O/-Onone since at -Onone I think we always serialize in OSSA today (just looking at the pass pipeline). Instead this is only about enabling this when compiling in -O. What about -enable-optimized-ossa-modules.

[atrick]

Looks good. I suggest enable-ossa-modules because we don't have any reason to separately control debug builds. Whereas I'm sure we'll want an -enable-optimized-ossa flag at some point to selectively push OSSA deeper in the pipeline and those shouldn't get mixed up.

[gottesmm]

@swift-ci smoke test

[gottesmm]

Turns out the problem was that there were certain tests that were simulating the stdlib and were relying on this behavior for serialization. I added the flag to the tests.