@relation type directive arguments for custom node type field names

[michaeldgraham]

The current way to define the head and tail node types of a @relation type requires the user to define from and to fields. For example:

Different types

  type Cause {
    id: ID! @id
    causes: [Event]
  }

  type Effect {
    id: ID! @id
    causedBy: [Event]
  }

  type Event @relation { #default name = "EVENT"
    from: Cause
    to: Effect
    description: String
  }

Same types

  type Cause {
    id: ID! @id
    effects: [Effect]
  }

  type Effect @relation {
    from: Cause
    to: Cause
    description: String
  }

This PR adds from and to arguments to the @relation type directive used by schema augmentation. The from argument is for the name of the node type field the relationship is coming from (head node), and the to argument for the node type it's going to (tail node). This results in adding a layer of customization for the names of node type fields defined for relationship types. This is a non-breaking change, as while the from and to field names can still be used, field names provided to the from and to arguments of the @relation type directive take precedence:

Different types

  type Cause {
    id: ID! @id

    "Every Cause causes at least one Event"
    causes: [Event]
  }

  type Effect {
    id: ID! @id

    "Every Effect is caused by at least one Event"
    causedBy: [Event]
  }

  type Event @relation(from: "cause", to: "effect") {
    "Every Event has a cause"
    cause: Cause

    "Every Event has an effect"
    effect: Effect

    description: String
    from: Int # Fields named 'from' or 'to' can thus be used for properties
    to: Boolean
  }

Same types

  type Cause {
    id: ID! @id

    "Every Cause has at least one Effect"
    effects: [Effect]
  }

  type Effect @relation(
    from: "causedBy", 
    to: "causes"
  ) {
    "Every Effect is caused by a Cause"
    causedBy: Cause

    "Every Effect causes a Cause"
    causes: Cause

    description: String
  }

This allows for more precise semantics when defining related node type field names, which in turn allows for more descriptive documentation comments. :)