Inlined relations api performance enhancements

As per the discussion on the [mailing list](https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/a533e26c-4f27-45ae-9e34-de793abbbe1b%40cloudfoundry.org?utm_medium=email&utm_source=footer) this PR adds three new query parameters to the CC api that can be used to selectively tweak the behaviour of the ```?inline-relations-depth``` query param.

```?orphan-relations=1``` - this de-duplicates the data in api responses. Instead of being inlined, nested objects are added to a  hash at the root level of the response, keyed by guid.  Clients have enough info in the response to reconstruct the original api response format.

```?exclude-relations=relation1,relation2``` - this drops named relations from all levels of the api response. e.g. ```/v2/apps?inline-relations-depth=2&exclude-relations=space``` would result in the space being dropped from the response.

```?include-relations=relation1,relation2``` - this includes only the named relations in all levels of the api response e.g ```/v2/apps?inline-relations-depth=2&include-relations=space``` would only include the inlined space, other inlined objects (like routes and events) would be dropped from the response.

Some high level performance numbers:

* ```/v2/apps?inline-relations-depth=2``` (default) = 171kb - 714ms
* ```/v2/apps?inline-relations-depth=2&orphan-relations=1``` (de-duplicated) = 38kb - 272ms
* ```/v2/apps?inline-relations-depth=2&orphan-relations=1&exclude-relations=events,app_events,stack,service_bindings,routes``` = 10.5kb - 83ms
* ```/v2/apps?inline-relations-depth=2&orphan-relations=1&include-relations=space,organization```  = 6.5kb - 54ms

Here's an example of how we transparently marshal the new api response structure back to the old structure in our JavaScript client, so that both formats are supported and no additional changes to clients are needed:

https://gist.github.com/Diggs/3050884e1c9ca9587829
Luan take a look at the latest commit. I went to put more depth in the collection renderer tests but couldn't actually think of anything worthwhile to test other than the high level JSON structure + url generation (which is exactly what the collection renderer deals with). The lower level tests are in the object serializer, which makes sense to me as that's the object that operates at that level. This is more or less the same testing structure that the existing inline-relations param has.