Support for Frameworks / Swift

This Pull-Request makes first steps to bring the long-awaited Swift support by supporting Frameworks. Along the way it keeps full backwards-compatibility with CocoaPods 0.35 and tries to break as few stuff as needed.
This PR supersedes #2222. See this for some of the original discussions.


##### Steps

To make that all happen, the following path was taken, described here very roughly:

* Recognize Swift source files by file accessors
* Extend the analyzer to decide when it is required to build a framework
* Generate a framework product type if required
* Generate a custom umbrella header to import all public headers and avoid naming conflicts
* Generate a custom module map to inject the umbrella header
* Namespace frameworks in directories in build path, as their naming is constrained
by underlying clang modules
* Migrate from a linked aggregate library to a linked framework (which is still just used instead of a target dependency to indirectly trigger the build of all pod targets)
* Link the built pod frameworks by build settings to the user target
* Set the build settings appropriate to reach all that
* Embed the built pod frameworks with a shell script build phase to the host application to allow configuration-dependent pods
* Auto opt-in OS X targets and iOS 8+ targets to dynamic frameworks (to be discussed in a separate issue, at the moment possibly more helpful for feedback)


##### What has happened so far:

All the steps described above. See the commits below. That's already a very condensed history, which was the result of a lot of trial-and-error and has been squashed to a reasonable length.


##### Checkout:

To get as much feedback as possible, feel encouraged to check out this branch in your local clone of [Rainforest](https://github.com/CocoaPods/Rainforest). If you use [bundler's local gem feature](http://bundler.io/v1.2/git.html), make sure that you checkout the right branches on the linked repos. (See below **Dependencies** for reference.) Make sure to run `bundle install`. You may want to make sure, that you install it to a gemset, you can use for the projects, you want to develop with. Right after that you should be able to install the CocoaPods gem with `rake install` to your current gemset.

If you use it and you mention a serve problem, like a crash appears or your xcodebuild fails:

1. Update your local copy. This crash could been already fixed. Please make sure to get a clean checkout from this branch as the upstream could have changed due to rebases, which could cause undesired local merges / conflicts.
* Search if someone has already created an issue for your problem, if so please take a look and provide more helpful information. If that's not possible, please don't `+1`, if not explicitly asked for it. We will try to solve all problems anyway.
* If there is no issue, please create a new issue, after reading our contribution guidelines. Prefix it with `[Frameworks]` and provide a reference to this Pull-Request on your newly created issue by referencing its number `#2835`.


##### Open Todos:

The following things are still open to do:

* [x] Add an example with Swift code
* [x] Add a fixture of *SwiftPod* for unit tests
* [x] Build podspecs for some OSS projects and test `pod spec lint`
* [x] Rebase after the release of 0.35.0
* [ ] Add missing unit tests
* [ ] Add dedicated integration tests
* [ ] More tests & experience with real-life projects
* [ ] Add a CHANGELOG entry


##### Dependencies:

This depends on the following PRs:

* [x] CocoaPods/Xcodeproj#166
* [x] CocoaPods/Core#195
* [ ] CocoaPods/cocoapods-integration-specs#17

/c @CocoaPods/core 
In that case, we could use a particularly name build phase like [Pods] Copy Frameworks so it’s easy to remove/readd on each install…

Any Idea why it would symlink the .framework instead of copy upon archive?

On Mon, Nov 24, 2014 at 5:23 PM, Marius Rackwitz <notifications@github.com>
wrote:

>> @@ -88,6 +114,58 @@ def self.add_library_build_settings(library_path, xcconfig, sandbox_root)
>>            xcconfig.merge!(build_settings)
>>          end
>>  
>> +        # Add the code signing settings for generated targets to ensure that
>> +        # frameworks are correctly signed to be integrated and re-signed when
>> +        # building the application and embedding the framework
>> +        #
>> +        # @param  [Target] target
>> +        #         The target.
>> +        #
>> +        # @param  [Xcodeproj::Config] xcconfig
>> +        #         The xcconfig to edit.
>> +        #
>> +        def self.add_code_signing_settings(target, xcconfig)
>> +          build_settings = {}
>> +          if target.platform.to_sym == :osx
> @flovilmart: The way you drafted, is what I tried first. The same issue with scoping exists for Copy Files Phases. Implicit target dependencies can be resolved by Xcode, that shouldn't be a problem anyway.
> There is even one more issue with that: We regenerate the targets in the Pods project on every `pod install` run. This causes changes to the user projects, which are likely undeseriable and can cause duplicate proxy entries, if they aren't garbage collected.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/CocoaPods/CocoaPods/pull/2835/files#r20827496