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 
Ok +1 for you.




Maybe just using a copy files phase instead of a script would solve the issue?

On Mon, Nov 24, 2014 at 5:10 PM, Samuel E. Giddins
<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
> The issue with using target dependencies for that is that it doesn't allow scoping dependencies to specific build configurations 
> -Samuel E. Giddins
> On Nov 24, 2014, at 2:02 PM, Florent Vilmart <notifications@github.com> wrote:
> In lib/cocoapods/generator/xcconfig/xcconfig_helper.rb:
>> @@ -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
> OK, I start thinking the workspace architecture is getting in the way of simplicity and reusability.
> Maybe the following changes would make sense:
> 1. Add each pod as a Target dependency item
> 1.a Add the pods project a a subproject (instead of a project in the same workspace)
> 2. Instead of a Copy Pods script phase, replace with a 'Copy File' Build phase with codesign on and each pod target
> What do you think? 
> That would actually make a lot of sense, instead of circumventing/R. engineer what Xcode's doing behind the scenes, just embrace the Xcode build strategy
> —
> Reply to this email directly or view it on GitHub.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/CocoaPods/CocoaPods/pull/2835/files#r20826608