executeField shouldn't assume that a selection has only one field with a
given name, but it should take the first field. The underlying cause is
a wrong pattern, which (because of the laziness) is executed only if the
field has arguments.
The functions generating errors in the executor should be changed anyway
when we provide better error messages from the executor, with the error
location and response path. So public definitions of these functions are
deprecated now and they are replaced by more generic functions in the
executor code.
The old function, addErrMsg, takes only a string with an error
description, but more information is required for the execution errors:
locations and path. addErrMsg should be deprecated after the switching
to the new addError.
I found some issues with directive definitions:
- I couldn't use `on FIELD_DEFINITION`, I believe because `FIELD` was parsed
first in `executableDirectiveLocation`. I've combined both
`executableDirectiveLocation` and `typetypeSystemDirectiveLocation` into one
function which can reorder them to ensure every directive location gets a fair
chance at parsing.
Not actually to do with directives, some literals weren't being parsed
correctly.
- The GraphQL spec defines list to be `[]` or `[Value]`, but empty literal lists
weren't being parsed correctly because of using `some` instead of `many`.
- The GraphQL spec defines objects to be `{}` or `{Name: Value}`, but empty
literal objects had the same issue.
