WIP: Support for defining pods per build config

This is not even nearly functional, I'm just prodding pieces of code to
see how it works.
[integrator] Add build-specific xcconfig to builds

Also fixes some typos from previous commit. Different xcconfigs are now
actually generated, correctly assigned, and it all builds! Doesn't pass
tests and all xcconfigs are still identical, but still: getting there!
[pod_target] Ask the targdef about config inclusion

https://github.com/lookback/Core/commit/affbeae85bd179c5e9a9a927a80f2aacc4d7cf7c
defines a new ":configurations" option for a pod, and exposes the corresponding
API. Using that API in include_in_build_config now lets aggregate_xcconfig
only include the build flags for the libraries that are used.

Next step is to make CocoaPods link using build flags, so that linking
can be disabled with an xcconfig.
Fix code style issues reported by @alloy
[installer] link using LDFLAGS instead of product reference

Since we want to do conditional linking, the list of Pods to link with 
needs to be provided by an xcconfig file. Only way to do that is to
remove the linking responsibility from Xcode and give it to ld directly.
config whitelisting: fix specs I broke

Fixes all the tests that broke with API changes of cocoapods internals
related to build configuration whitelisting

Should've fixed these inline when I made the changes, but I didn't :(
config whitelisting: fix some more specs

* missed fixing three calls to xcconfig_relative_path
* Added parens to a call while at it
[Bundle] Update.
Small syntax cleanups.
[Core] Update syntax change.
[Analyzer] Get all configurations from the user project, including Debug and Release.
[Installer] Validate the configs a pos is whitelisted for.
[xcconfig] Only quote the path to the -isystem option.
[CHANGELOG] Document a few adhoc fixes.
[Bundle] Update.
[AggregateTargetInstaller] Only pass around the build config name.
[spec] Update integration fixtures.
Added 8 tests for issue #1489, one of which is failing. The failing test reproduces the issue that @jomnius reported with the < version operator. One of the passing tests checks the question that @alloy asked about using ~> with a pre-release version. The other passing tests verify correct behavior with the other version operators when dealing with pre-release versions.
Merge remote-tracking branch 'upstream/master'
[Gemspec] Update to nap 0.8