Fixed issue where:

• IF: a query has multiple fragment spreads in a field set
• AND: those fragments could be mergeable
• AND: one of the fragment's graph type is unresovable
• THEN: An execution exception would be thrown causing a 500 error instead of triggering rule 5.5.1.2

This query should trigger 5.5.1.2 but was crashing the query (resulting in a hard 500 response)

{
    search{
        ... on Human {
            id
            name
        }

        # Note incorrect casing on Droid
        ... on DRoid {
            id
            name
            __typename
        }    
    }
}

• The correct validation rule will now be triggered with appropriate messaging with this PR.

• Also updated the 5.5.1.2 error message for inline fragments to include the failed type name to add additional clarity.

Previous Catastrophic error message:

Response Code: 500
Unknown Internal Server Error

New Corrected Error Response

{
  "errors": [
    {
      "message": "No known graph type was found for the target fragment (Target: 'DRoid').",
      "locations": [
        {
          "line": 7,
          "column": 5
        }
      ],
      "extensions": {
        "code": "INVALID_DOCUMENT",
        "severity": "CRITICAL",
        "metaData": {
          "Rule": "5.5.1.2",
          "RuleReference": "https://spec.graphql.org/October2021/#sec-Fragment-Spread-Type-Existence"
        }
      }
    }
  ]
}