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 
Makes sense.


I've investigated further my archive problem and it seems that the pods framework are only symlinked in the target .app. Which is why it refuses to install through the IPA / OTA.

Is it me?

On Sun, Nov 23, 2014 at 12:49 PM, AliSoftware <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 Yes, but this is not the only use case when Code Signing is needed.
> It is also needed when building for phoneos to test on your device for example.
> Besides, releasing a version (OTA release for example) is not always done using the "Archive" action (or `-exportArchive` flag from the command line).
> E.g our CI server does a simple build (`xcodebuild … -configuration Release -sdk iphoneos`) then creates and upload everything needed on our distribution server. _We don't want an archive in this situation because it would fill the disk space pretty fast considering the number of releases our build server does._
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/CocoaPods/CocoaPods/pull/2835/files#r20766310