nestedMutationsSimpleFieldNames inflection conflict with multiple FKEY relations to same table

[frankdugan3]

Given the table:

CREATE TABLE hsm_public.gage_calibration_record (
  id uuid PRIMARY KEY DEFAULT uuid_generate_v1mc(),
  -- ...
  gage_id uuid NOT NULL REFERENCES hsm_public.gage(id) ON DELETE RESTRICT,
  standard_id uuid REFERENCES hsm_public.gage(id) ON DELETE RESTRICT
);

The following input type is generated:

input CreateGageCalibrationRecordInput {
  id: UUID
  # ...
  gageId: UUID
  standardId: UUID
  gageToGageId: GageCalibrationRecordGageIdFkeyInput
  gageToStandardId: GageCalibrationRecordStandardIdFkeyInput
}

So far, so good. But when I use the nestedMutationsSimpleFieldNames: true option, it simplifies to this:

input CreateGageCalibrationRecordInput {
  id: UUID
  # ...
  gageId: UUID
  standardId: UUID
  gage: GageCalibrationRecordStandardIdFkeyInput
}

This convention steamrolls the second relation to the gage table, and it removes the clarity provided by the column's original name. Perhaps it could use the column name for inflection rather than the foreign table? At the very least, if more than one FKEY points to the same table, it should skip simplification. Since [relation]_id is a pretty common convention, FKEY columns that match that format could simply strip _id from the column name, producing for my example:

input CreateGageCalibrationRecordInput {
  id: UUID
  # ...
  gageId: UUID
  standardId: UUID
  gage: GageCalibrationRecordGageIdFkeyInput
  standard: GageCalibrationRecordStandardIdFkeyInput
}

[mlipscombe]

This can be worked around at least by using @forwardMutationName and @reverseMutationName to set the nested names as you wish.

Special casing [relation]_id would be a schema-breaking change for existing users, so it would have to be gated behind a configuration option, or part of a major version bump.