Refine ProjectedPayload argument handling for an optional input argument

[rstoyanchev]

A @ProjectedPayload method parameter can be declared with java.util.Optional as of #506, and that allows handling optional input arguments. We should allow it to be declared with ArgumentValue, introduced in #518.

If neither wrapper is used, currently ProjectionFactory fails with IllegalArgumentException if the input value is null. We should change that to allow null to be passed in if we want it to be consistent with the handling of regular @Argument method parameters. This allows the controller method to handle a null argument value.

Alternatively, we could keep the current behavior of the @ProjectionPayload argument handling, in effect requiring an optional wrapper for optional input, and otherwise rejecting it. In this case, we should also align the handling of regular @Argument parameters to do the same. That would be a breaking change, however, for an application that handles the null within he controller method.

[rstoyanchev]

Tentatively scheduling for 1.1.1 since this is a missed aspect of the argument binding improvements in 1.1. However, we should weigh in when to introduce the parts that bring breaking behavior.

[rstoyanchev]

We've discussed this and decided to change ProjectedPayloadArgumentResolver to allow null to be passed in. If an argument is required in the first place, it will be rejected by GraphQL Java. If it is optional and the method parameter is declared as an object, then that becomes null.