perf improvements for fragment cycles validation

[jbellenger]

We've observed that some of our real-world queries are taking seconds to validate.
When profiling these queries, it looks like the validation time is dominated by the NoFragmentCycles rule.

This PR reworks NoFragmentCycles to not traverse into fragments that have already been visited anywhere in a fragments transitive dependencies. This is similar behavior to the graphql-js implementation and adheres to 5.5.2.2 Fragment spreads must not form cycles. This PR should result in no external behavioral changes.

This change improves the validation time for one of our fragment-heavy queries by over 100x.
I've added an anonymized version of our schema and query as new resources, which are measured below as a new "manyFragments" benchmark:

Before:

Benchmark                         Mode  Cnt     Score    Error  Units
ValidatorBenchmark.largeSchema1   avgt   40     0.070 ±  0.002  ms/op
ValidatorBenchmark.largeSchema4   avgt   40    24.214 ±  0.168  ms/op
ValidatorBenchmark.manyFragments  avgt   40  1255.602 ± 11.135  ms/op

After:

Benchmark                         Mode  Cnt   Score   Error  Units
ValidatorBenchmark.largeSchema1   avgt   40   0.069 ± 0.001  ms/op
ValidatorBenchmark.largeSchema4   avgt   40  25.289 ± 0.299  ms/op
ValidatorBenchmark.manyFragments  avgt   40  10.979 ± 0.151  ms/op

Side note:
I had some issues using Anonymizer with built-in directives. It seemed to generate assertion errors when @include was applied to a selection set, like:

fragment Foo on Bar {
  field @include(if: true) {
     x
  }
}

I didn't have the context to understand what Anonymizer expected in this case so I didn't dig into it too much, though I'm happy to privately share a query+schema that triggered this if that helps.

[jbellenger]

this test is a duplicate of "no co-recursive spreads in floating fragments"

[jbellenger]

this test is a duplicate of "no self-spreading in floating fragments"

[dondonz]

FYI @jbellenger I updated your branch and resolved merge conflicts to get this ready for release. Thanks so much!