Define input enums in WHERE HAS conditions

[DrPowerSlam]

Created as issue instead, sorry for the discussion noise: #2723

When defining a WHERE HAS query with a condition in complex queries, Lighthouse will fetch the column enums from the parent type, not the relation, if the where definition uses any sort of column enumeration.

{
  drivers(
    where: {
      OR: [
        {HAS: {relation: "employee", condition: {column: NAME, value: "Peter"}}}, // `column: DriverColumnEnum` instead of `column: EmployeeColumnEnum`
        {column: ID, operator: EQ, value: "6217"} // `column: DriverColumnEnum`
      ]
    }
  ) {
    data {
      id
      name
      employee {
        name
      }
    }
  }
}

I think it would make sense if you could define the relations in a where, the same way we do in orderBy:

extend type Query {
    "List multiple drivers."
    drivers(
        orderBy: _ @orderBy(
            columnsEnum: "DriverColumn",
            relations: [{relation: "employee", columns: ["name"]}]
        )
        where: _ @whereConditions(
            columnsEnum: "DriverColumn",
            relations: [{relation: "employee", columns: ["name"]}] // or columnsEnum.
        )
    ): [Driver!]! @paginate(defaultCount: 10)
}

This would both enable stronger schema generation by having enums for the relation name (right now it's currently just a string), make orderBy and where more similar in how they are written in the schema definitions, and of course fix the issue described in the discussion link below.
One of the huge benefits of using enum types in the schema, is that the schema documentation can explain exactly what a API consumer can use, so I think this would be the absolute best solution for usability. Otherwise a API consumer will need intricate knowledge of the database columns available.
I think it would also make sense that the relations.column type will default to String if column enumerations are missing, instead of trying to resovle the column enum type of the parent.

Thanks for taking your time to consider this. :)

Original Q&A discussion this is based on: #2720 (comment)