TCK tests for the First anno

[njr-11]

Adds TCK tests for the @First annotation, covering usage with @Find and @Query, obtaining a single result or multiple results, including cases where there are less results available than the requested First amount.

Resolves #532

[KyleAure]

Looks good. While I was reviewing this I thought of a couple of missing negative tests:

• Verify a repository method with the @First annotation and a Limit parameter throws an UnsupportedOperationException
• Verify a repository method with the @First annotation and the First keyword (query by method name) throws an UnsupportedOperationException

I think it would also be useful to have one of the repository methods return an array instead of a List since there is an example of that in javadoc.

I did not find this scenario discussed, but should the following repository method work, or be rejected?

    @Find
    @First
    List<Country> leastBy(Sort<Country> sort);

We left the default value 1 but still want to return a list. Not something I'd expect a user to WANT to do, but we might want to document what behavior we expect.

[njr-11]

Thanks Kyle - those are some good comments.

* Verify a repository method with the `@First` annotation and a `Limit` parameter throws an `UnsupportedOperationException`

* Verify a repository method with the `@First` annotation and the `First` keyword (query by method name) throws an `UnsupportedOperationException`

According to the spec, UnsupportedOperationException is one option, but the Data provider alternatively has the option to fail these at build time, so while the above are good ideas to have coverage for, it will be something for Data providers to test on their own.

I think it would also be useful to have one of the repository methods return an array instead of a List since there is an example of that in javadoc.

added in the latest commit

I did not find this scenario discussed, but should the following repository method work, or be rejected?

    @Find
    @First
    List<Country> leastBy(Sort<Country> sort);

We left the default value 1 but still want to return a list. Not something I'd expect a user to WANT to do, but we might want to document what behavior we expect.

Yes, the spec allows this usage. Although it is not often likely to be useful, I don't see a good reason to go out of our way to add extra language in the spec saying that it must be rejected. I added a test for it.

The latest commit also rebased to resolve a merge conflict.