Allow GraphQL schema shorthand configuration

[ir-regular]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Documented?	no
Fixed tickets	#12
License	MIT

This PR adds the ability to define your schema in GraphQL schema shorthand.

It requires library version updates (patch version level) for better comment handling. Comments are the mechanism by which you can define elements that aren't reflected in schema shorthand: descriptions, resolvers and custom enum value values.

WIP - "men at work" warning - assume this branch will be rebased.

TODO, reminder to self:

• clean up OverblogGraphQLTypesExtension::parseSchemaToOverblogGraphQLTypesConfigArray()
• add unit tests (loading of the new configuration type etc)
• add ability to load multiple types of configuration files from the same directory
• add documentation with examples (esp. resolvers and custom enum value values)
• add credits on collaborated code
• improve commit messages where needed

[mcg-web]

Hi @jane-olszewska,
Thank you for the contribution, I think that we should keep the schema totally compatible with the specs so doing leaves the possibility to use it with other servers if needed. If builders are not supported by this implementation, that's not a big deal. For resolvers, we can maybe introduce resolverMap like apollographql/graphql-tools? For the parser it may be time to introduce dedicated parser for each type...
That a huge work, tell me what you think of all this.

[ir-regular]

Hi @mcg-web :)

I think that we should keep the schema totally compatible with the specs so doing leaves the possibility to use it with other servers if needed.

At the moment, it is compatible in that it won't break validation when moved over to different servers (and it's very easy to strip out by matching to a regexp). (In comparison to other extensions, a bit more compatible than for example + based syntax for decorators as introduced in the apollo extension.)

If builders are not supported by this implementation, that's not a big deal. For resolvers, we can maybe introduce resolverMap like apollographql/graphql-tools?

The resolvers are already declared as services and tagged appropriately so maybe it would be better to add custom attributes to service tags (a combination of type/field)? But the most convenient option would be to be able to jump from the type definition straight to the resolver method.

For the parser it may be time to introduce dedicated parser for each type...

WDYM?

That a huge work, tell me what you think of all this.

Yeah, so this PR is an extract of code I wrote for another project as you can tell by the 'todo' comments in the code (that will be cleaned up). Unfortunately, I don't currently have a lot of time to spend on expanding the library, but I thought people might make use of it as it is, even if the functionality is a bit limited.

[mcg-web]

I think this new feature of webonyx/graphql-php could help a lot on this webonyx/graphql-php#91...