Only include the platform PrivateFrameworks directory as a runtime, not build-time, search path

[stmontgomery]

This constrains a behavior I landed in #8199 so that it only includes the PrivateFrameworks directory from Xcode's platform directory (when present) as a runtime framework search path (via DYLD_FRAMEWORK_PATH) and no longer includes it as a build-time framework search path (via -F <path>).

Motivation:

This is a follow-up to a change I made in #8199. Those changes had an undesirable side effect of including private frameworks in all builds, and means that when those frameworks are present at build time, they're included in client builds and can be import'ed or linked. Exposing those frameworks to clients at build-time was not intended, and can cause unexpected results or failures if (for example) those private frameworks themselves contain unresolvable module imports.

However, platform private frameworks directories should continue to be included in runtime framework search paths, so they can be located and loaded when referenced by public frameworks/libraries.

Modifications:

• Introduce separate properties for build-time vs. runtime framework and library search paths, so the two categories can be differentiated by callers.
• Omit the private frameworks search path from the new build-time frameworks property.
• Adopt the relevant new properties at both build and runtime usage sites.

Result:

After this change, I validated that:

• a local package build no longer contains the private frameworks search path entry at build time, using swift build --build-tests --verbose, and
• a local package test operation still includes the search path, using env DYLD_PRINT_ENV=1 swift test.

[stmontgomery]

@swift-ci test