Add support for projected payloads

[mp911de]

Controller methods now accept interface projections for individual or all
request arguments when Spring Data is on the classpath.

Closes gh-197

[andimarek]

I want to point out that argument values are coerced by GraphQL Java before made accessible via DataFetchingEnvironment. This means for custom Scalars coercing is basically a competing mechanism to HandlerMethodArgumentResolver in some way.

For example:

{ search(input: {foo: "bar", foo2: 1233}} }

for this schema:

scalar MyInputScalar
type Query {
  search(input: MyInputScalar): String
}

I can implement MyInputScalar in a way which returns for example a SearchValue object which can be anything.

I think that is an edge case, but I want to highlight it anyway. cc @rstoyanchev

[rstoyanchev]

@andimarek, a HandlerMethodArgumentResolver is just a contract which can be used to implement support for extracting anything from DataFetchingEnvironment and injecting that into a controller method. In that sense, it's not inherently competing with custom scalars. It depends on the specifics of how a resolver is implemented.

Keep in mind that for M3, we changed how an @Argument annotated method parameter is resolved, to use the values in the DataFetchingEnvironment#getArguments() map and apply them to properties of the target object. This was specifically meant to ensure we respect such custom scalars that have already been deserialized by GraphQL Java. You can see #122 for that.

The ProjectedPayloadMethodArgumentResolver added in this PR also works by looking up values in the DataFetchingEnvironment#getArguments() map so that should be okay too, as far as I can see.