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
The basic idea here seems great and a it's a big efficiency win. We're a little concerned about the complexity of this method. Now that we have all these nested `if`s and `else`s the logic becomes quite hard to read and maintain (and, for example, in one case we do `orphans.nil?` and in one we do `orphans == nil` as the guard: it feels brittle). 

We'd suggest it might make sense to split out two objects, one to serialize relationships the old way, and one to do orphaned relations (for example these might be called `InlineRelationshipsSerializer` and `OrphanedRelationshipSerializer`). We could move any common logic to a shared helper or base class of those objects if necessary. This way we would not need the repeated tests and branches, and instead we would just call `.serialize` on an object (which would be one or the other implementation depending on the query parameter). This would make each implementation easier to test, read and maintain. This might also help with the increasingly enormous parameter list this method now has, which seems like a 'smell' indicating we should pull out some objects here instead (i.e. we could just pass in a serializer which, if it were on `OrphanedRelationshipSerializer` would already be configured with the relationships to exclude and include).