[Post] Add draft of CocoaPods 0.35 release post

\c @orta @alloy
+1

> It could be as simple as a # relies on AFNetworking X.Y.Z

I agree that keeping this very simple would illustrate it well, especially by adding an _after_ version as well. E.g.

> Consider the following Podfile and note that CocoaPods will by default, when no version requirements are specified, try to activate the latest available version of a pod. (The versions in this example are based on the latest available versions of the pods in question _at the time of writing_).
>
> ```ruby
> pod 'AFAmazonS3Client' # Version 2.0.0 activates AFNetworking with requirements: >= 2.0.0 && < 3.0.0
> pod 'CargoBay'                # Version 2.1.0 activates AFNetworking with requirements: >= 2.2.0 && < 3.0.0
> pod 'AFOAuth2Client'      # Version 0.1.2 activates AFNetworking with requirements: >= 1.3.0 && < 2.0.0
> ```
>
> From the above, it is clear that the latest versions of `AFAmazonS3Client` and `CargoBay` are not compatible with the requirements of `AFOAuth2Client`. As such, the new resolver will now **backtrack** and try to satisfy the requirements of `AFOAuth2Client` by looking for **older** versions of `AFAmazonS3Client` and `CargoBay` that are compatible with `AFNetworking` versions between `1.3.0` and `2.0.0`.
>
> The new resolver ends-up activating the following versions of the specified pods:
> ```ruby
> pod 'AFAmazonS3Client' # Version 1.0.1 activates AFNetworking with requirements: >= 1.3.0 && < 2.0.0
> pod 'CargoBay'                # Version 1.0.0 activates AFNetworking with requirements: >= 1.0.0 && < 2.0.0
> pod 'AFOAuth2Client'      # Version 0.1.2 activates AFNetworking with requirements: >= 1.3.0 && < 2.0.0
> ```
> And thus activating `AFNetworking` version `1.3.4` which is the last minor version of the `1.x.x` series.