Fragment spread on interface type with no implementers

Hi! I think this may be a spec bug.

Say I have an interface with no implementers.

```graphql
interface Intf {
field: Int
}
type Query {
intf: Intf
}
```

I can query this field and its subfields. It doesn't really make sense as `intf` can officially never return any concrete type but it does validate. So far so good.

```graphql
query {
intf { field }
}
```

However, if I put a fragment spread in there, with type condition `Intf` (i.e., the spread is useless because it's exactly the parent type), I believe the spec says that I should receive an error:

```graphql
query {
intf {
... on Intf { field }
}
}
```

The [Fragment Spread Is Possible](https://spec.graphql.org/draft/#sec-Fragment-Spread-Is-Possible) rule dictates that this should check if the possible types of `Intf` and `Intf` should intersect. The possible types are defined as the set of types implementing `Intf`. This set is empty, so they don't intersect, so I believe the fragment spread should not be possible.

graphql-js accepts this query, because it first checks if `typeCondition == parentType` ([source](https://github.com/graphql/graphql-js/blob/9a91e338101b94fb1cc5669dd00e1ba15e0f21b3/src/utilities/typeComparators.ts#L95-L97)). graphql-go and graphql-java follow JS. In apollo-rs, we implemented the spec steps as written, as an intersection between `GetPossibleTypes()` ([source](https://github.com/apollographql/apollo-rs/blob/d710f4649c4f31d68dc34e9bfe023c301eacc0be/crates/apollo-compiler/src/validation/fragment.rs#L72-L75)), so apollo-rs rejects the query.

I think the graphql-js behaviour makes more sense, but as far as I can tell, it's not aligned with the spec. Should the spec be changed to fit, with an early bailout in the Fragment Spread Is Possible rule?