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
Can we have this "parsing" be out of this object? It seems to me that parameter parsing should be a controller concern and this object should restrain its responsibilities to dealing with serialization.