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, 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