Rework isFragmentReady API

### Is your feature request related to a problem? Please describe.

Today, if multiple fragments select the same fields, but have a different selection set within the individual fields that resolve to an object type or similar, will give false results.

**Example:**

```graphql
fragment A on Object {
a
b {
c
}
}

fragment B on Object {
a
b {
d
}
}

query Foo {
a
...A @defer
...B @defer
}
```

Since we only check whether the fields on the query type (`Query.a`, `Query.b`) exist within the `isFragmentReady` helper, even if only the data for the `A` fragment arrived on the client, the `isFragmentReady` helper will return `true` for the check on the `B` fragment.

Instead,we should focus on a new API that first drops the need for passing the operation document node to `isFragmentReady`, but also does structural data checks on whether all the data selected within the fragment is satisfied within the object provided.

That will require storing a minimal representation of all the fragment fields (and also subfields) within the `TypedDocumentNode` / `TypedDocumentString`.

### Describe the solution you'd like

-

### Describe alternatives you've considered

_No response_

### Is your feature request related to a problem? Please describe.

_No response_