Add support for the @auth directive

[Andy2003]

Add support for an @auth directive to fine tune access control to the schema.

The directive should look like:

# You can put the `@auth` directive also on a field with the `@cypher` directive.
# Functionality like allow and bind will not work but you can still utilize `isAuthenticated` and `roles`.
# Notice you don't need to specify operations for `@auth` directives on `@cypher` fields.
directive @auth(
  # You can have many rules for many operations.
  # We fallthrough each rule, on the corresponding operation, until a match.
  # On no match, an error is thrown. You can think of rules as a big OR.
  rules: [AuthRule!]!
) on FIELD_DEFINITION|OBJECT

input AuthRule{
  # Operations is an array, you can re-use the same rule for many operations.
  operations: [AuthOperations!]
  # This is the most basic of auth. Used to ensure that there is a valid decoded JWT in the request
  isAuthenticated: Boolean
  # Use the roles property to specify the allowed roles for an operation.
  roles: [String!]

  # Use allow to ensure, on matched nodes, a connection exists between a value on the JWT vs a property on each matched node.
  # Allow is used on the following operations:
  #  * read
  #  * update
  #  * connect
  #  * disconnect
  #  * delete
  # When you specify allow on a relationship you can select fields on the referenced node.
  # It's worth pointing out that allow on a relationship will perform an `ANY` on the matched nodes: to see if there is a match.
  # Allow works the same as it does on Type Definitions although its context is the Field.
  # So instead of enforcing auth rules when the node is matched and or upserted, it would instead be called when the Field is selected or upserted.
  allow: Object
  # Use bind to ensure, on creating or updating nodes, a connection exists between a value on the JWT vs a property on a matched node.
  # This validation is done after the operation but inside a transaction.
  # Bind is used on the following operations:
  #  * read
  #  * update
  #  * connect
  #  * disconnect
  #  * delete
  # There may be a reason where you need to traverse across relationships to satisfy your Auth implementation.
  # One example of this could be "Ensure that users only create Posts related to themselves"
  # When you specify `bind` on a relationship you can select fields on the referenced node.
  # It's worth pointing out that allow on a relationship will perform an `ALL` on the matched nodes; to see if there is a match.
  # This means you can only use `bind` to enforce a single relationship to a single node.
  # You can use bind on a field. The root is still considered the node.
  bind: Object
  OR: [AuthRule!]
  AND: [AuthRule!]
}

enum AuthOperations {
  # MATCH
  read
  # CREATE
  create
  # SET
  update
  # DELETE
  delete
  # MATCH & MERGE
  connect
  # MATCH & DELETE
  disconnect
  # permit for all operations
  all
}

scalar Object

Currently this directive cannot be handled by the graphql library used in this project due to following issues:

graphql-java/graphql-java#2238

graphql-java/graphql-java#2239

so before working on this issue we should wait for the related issues to be fixed.