Allow installation of a pod with its own Swift version on multiple targets

Show warning when SDK provider tries to push a version with an unencrypted HTTP source

Add information about how to run tests

This is something that took me a few minutes to find, so let's make it easier for new people to know how to run a specific test, as that's very commonly used when preparing a PR. 

As there is a lot of potential small changes in this PR, please feel free to directly apply any changes and merge from there.

Integrate `swift_version` DSL support into pod targets

Related to https://github.com/CocoaPods/CocoaPods/pull/7249, fixes https://github.com/CocoaPods/CocoaPods/issues/7238

I'll add tests, once I get the ok that this is the right location and the right approach. For now I used the `error` method to fail the validation. I believe that it's the right thing to do, there is no good excuse to transfer executable over non-encrypted protocols, however I do understand that this might throw off some SDK providers, and them being overwhelmed when they quickly need to push an update.

You all have more context around what the users are like, and if they have a way to work around this, just let me know what you're deciding on 👍

[XCConfigHelper] Quote framework names in OTHER_LDFLAGS

Fixes #7185

Fix static framework archive regression from #7187

Create scripts for every test target's configuration

Set `SWIFT_VERSION` to test native targets during validation

Add copied resources' paths to "Copy Pods Resources" output file list 

Do not link system frameworks of test specs to library targets

Add color indication to output of "pod outdated"

Static library headers should all be Project

Fix CHANGELOG entries

Be more lenient when stripping frameworks and dSYMs for non fat binaries

Fix unnecessary whole project recompilation