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 
Code Signing should happen upon archiving the base project no?

On Sun, Nov 23, 2014 at 11:52 AM, 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
> Be careful, CodeSigning is not always wanted, for example on our CI server we build & test using the `-sdk iphonesimulator` and we dont CodeSign, to be sure we won't have CodeSigning issue just because our CI don't have all the Provisioning Profiles installed.
> _For example one of our latest app uses HealthKit, which needs specific entitlements, leading to a Provisioning Profile specific for this app. We don't want to have to copy/install the Provisioning Profile on our CI each time an app has a specific PP needed, that's why we prefer our CI not to CodeSign._
> Making CP force the CodeSigning of the Swift frameworks it integrates could this lead to problems. We should only CodeSign if the target SDK is iphoneos (or OS X), and not iphonesimulator. Better yet, we should use the same settings for the Swift frameworks that is used for the app.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/CocoaPods/CocoaPods/pull/2835/files#r20765755