Remove @_implementationOnly imports guarded by 'SWT_BUILDING_WITH_CMAKE'

[stmontgomery]

This removes the SWT_BUILDING_WITH_CMAKE compilation condition, and the @_implementationOnly import _TestingInternals declarations it guards.

Motivation:

When support for building via CMake was first added (in #387), many source files in the Testing target were modified to avoid using private- or internal-level imports of the _TestingInternals module and instead use the older @_implementationOnly import style when building via CMake. As a result, many files have:

#if SWT_BUILDING_WITH_CMAKE
@_implementationOnly import _TestingInternals
#else
private import _TestingInternals
#endif

This has proven to be a maintenance problem for us, because as new files are added over time, it's not immediately obvious that they need to use this pattern for importing this module—leading to warnings when building with CMake such as the one fixed by #553.

I wasn't aware of the reasoning behind the above change at the time, but I investigated it recently and here's what I concluded: Early on, the changes in #387 did not enable Library Evolution (LE) for the Testing module, meaning it was still a non-resilient module. SE-0409 states that all dependencies of non-resilient modules must be loaded by clients, so it would make sense that under those conditions, the build of a client who imports Testing would fail because clients do not have visibility to the _TestingInternals module. However, in a later PR commit LE was enabled, but nobody realized that those import code changes were no longer necessary and could be reverted.

I was able to reproduce this and confirm the theory: I added an example client target in the CMake build, then disabled LE in the Testing module, and attempted to build the client. It failed with the expected missing module error. Then, re-enabling LE and rebuilding everything, the error went away. Hopefully this is sufficient proof that reverting this is safe, but I'll check with the main contributor of that PR to check and see if there were any other issues before landing.

But overall, the goal here is to simplify these imports to reduce maintenance burden and fully embrace SE-0409.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[stmontgomery]

@swift-ci please test

[stmontgomery]

@jeffdav and @compnerd, does my paragraph in the PR description above trying to reconstruct the history seem correct to you? Do you recall any other problems you originally encountered, besides Library Evolution, which led you to need these changes to these imports?

I know there was also some discussion about package access level, but this project doesn't include any package-level imports.

[grynspan]

Let's leave this in actually, as it may come in handy in the future that we're able to distinguish CMake from SwiftPM and xcodeproj builds.

[stmontgomery]

I thought about that, but in retrospect I think this sort of pattern would be better accomplished with feature-scoped guards. For example, I think this one could have been phrased as SWT_NO_ACCESS_LEVEL_IMPORTS, matching some of our other build time conditionals. So I will proceed with removing this, and we can easily add back other, more specific conditions in the future the need arises.

[compnerd]

Yes, the description seems accurate and complete to me.