feat: support pre-parsed queries (eg. graphql-tag)

[voxpelli]

If one want to be using eg. graphql-tag to manage queries and fragments, then currently one can't do queries with the Mercurius reply.graphql() or fastify.graphql().

This PR changes that by making Mercurius accept pre-parsed queries.

To achieve that I had to:

• Swap tiny-lru for a quick-lru as the later is built on top of Map and as such accept non-string keys.
  • Since quick-lru is an ESM-module, its lazy-loaded and buildCache was made async, with minor/no impact to anything
• When input is already parsed:
  • preParsingHandler is skipped
  • Parsing step is replaced by a structuredClone(source) (to ensure that the cache values will not be saved by reference in any part)

JIT:ing etc still works like it works for any other query

[voxpelli]

Same failure as in #1109, will work after fix there

[voxpelli]

Rebased after #1109 got merged, now passes tests 👍

[mcollina]

lgtm

[voxpelli]

For future reference – this enables having colocated fragments easily:

file-a.js:

import { gql } from 'graphql-tag';

export const linkableNamedEntityFragment = gql`
  fragment LinkableNamedEntity on NamedEntity {
    id
    name
  }
`;

file-b.js:

import { gql } from 'graphql-tag';

import { linkableNamedEntityFragment } from './file-a.js';

export const fooFragment = gql`
  fragment Foo on NamedEntity {
    ... LinkableNamedEntity
    bar
  }
`;

file-c.js:

import { gql } from 'graphql-tag';

import { linkableNamedEntityFragment } from './file-a.js';
import { fooFragment } from './file-b.js';

export const adminEntityQuery = gql`
  query adminEntity($type: EntityType!, $id: ID!) {
    entity(type: $type, id: $id) {
      __typename
      createdAt

      ... LinkableNamedEntity

      ... on OrganizationOwned {
        owner {
          ... LinkableNamedEntity
          ... Foo
        }
      }
  }
  ${linkableNamedEntityFragment}
  ${fooFragment}
`;

Eg. the VSCode extension will understand that the fragments are imported and not complain about invalid names of fragments + graphql-tag will dedupe the fragments, so unlike string concatenation that would result in duplicate definitions of fragment LinkableNamedEntity in the above no such duplication will occur.

So all in all – what might look as a taste in coding style on the surface actually has some distinct benefits beneath the surface :)

(Wanted to add this here for future reference for others now that I had implemented it in my project myself)