Allow model references in custom query return types

**Is your feature request related to a problem? Please describe.**
In Gen 1 it was possible to declare a custom query where the return type referenced a composite that included a modelled type. This was useful if you wanted to write a custom query backed by a lambda function, but the results could still be expanded via the GraphQL API and automatically resolved by AppSync.

Gen 1 example:
```
type Query {
getItemData(someParam: String): ItemDataResponse
@function(name: "getItemData-${env}")
}

type ItemDataResponse {
items: [Item]
nextToken: String
}
```

This does not seem to be possible in Gen 2. This error is shown on deployment: "Cannot use .ref() to refer a model from a custom type"

Gen 2 example:
```
ItemDataResponse: a.customType({
items: a.ref('Item').array(),
nextToken: a.string()
}),
getItemData: a.query()
...
.handler(a.handler.function(getItemData))
.returns(a.ref('ItemDataResponse'))
```

or a simpler alternative:

```
getItemData: a.query()
...
.handler(a.handler.function(getItemData))
.returns(a.customType({
items: a.ref('Item').array(),
nextToken: a.string()
}))
```

When working with DynamoDB, paging tokens are pretty fundamental, so I struggle to see how you can provide custom queries for modelled data, unless I'm missing something here.

I know that a migration tool for Gen 1 to Gen 2 has been under development for a good while - surely this support would be a prerequisite for that, as I'm sure we are not the only users doing similar things.

**Describe the solution you'd like**
If I have a type `Item` then I would like to be able to write a custom query backed by a lambda function that returns an array of `Items` along with a `nextToken`, so that I handle the paging of DynamoDB in my lambda function.

The use of a reference to an existing modelled type here is important, as it allows a user of the GraphQL API to expand any relationships from an `Item` and have AppSync automatically resolve them.

Obviously, this is a single, simple example. There are more complex return types too that could be a composite of various modelled entities.

I would not necessarily expect any authentication rules on the referenced type to be generated, as in writing a custom function this is effectively taking responsibility for the auth checks.

**Describe alternatives you've considered**
Duplicating the definition and attributes for the type ('Item'). This is only partially useful as it is not the modelled item, so any relationships are not supported, and you lose the power of AppSync and the GraphQL schema.

**Additional context**