Federation - Suggestion to move from _service as SDL to actual types

Had a chance to look through the Apollo Federation solution and spec. I love the idea of being able to compose services in a declarative way.

However I feel like the current specification of the Federation approach is a little clunky. In particular the new `_service` field which is basically a printed SDL with the proper directives still attached. This feels like it heavily favors implementations that use an SDL first approach (as code-first approaches would require additional tools to re-construct the schema in SDL form with all these directives attached).

I was wondering what the stance on this is going forward? I'm wondering if the spec of the `_service` field could become more standardized and use the native graphql type system to expose this sorts of metadata (and not via a special schema print).

At first glance, this is what I came up with looking over the spec (I most likely missed things):
```graphql
type _Service {
_types: [_FederatedTypeMetaData!]!
}

type _FederatedTypeMetaData {
_type: String! # 'User'
_key: _FieldSet! # ['id']
_provides: [_FederatedTypeProvidesMetaData!]! # { _field: 'product', _provides: ['name'] }
_requires: [_FederatedTypeRequiresMetaData!]! # { _field: 'reviews', _requires: ['email'] }
_externals: [_FederatedTypeExternalMetaData!]! # { _field: 'email' }
_extends: Boolean! # true
}

type _FederatedTypeProvidesMetaData {
_field: String!
_provides: _FieldSet!
}

type _FederatedTypeRequiresMetaData {
_field: String!
_requires: _FieldSet!
}

type _FederatedTypeExternalMetaData {
_field: String!
}
```

This would be a more approachable solution for other languages and more importantly a lot more code-first approaches (such as `nexus`) as this is just expanding the schema by using built-in type systems (and not needing for an enhanced print behavior).