[Bug] SchemaLink and Async schema duplicated GraphQL instance

Based on #188 having a Schema that is created async will give us lots of problems trying to use `SchemaLink`, the current state is that we can avoid using an absolute URL for the `HttpLink` if we use `SchemaLink` on the SSR side, however, if the Schema is generated async we need to handle the promise before it even lands in the `ApolloNextAppProvider`'s `makeClient` factory, which doesn't accept async factories.

The following was recommended as a way to handle the promise properly, it works and the site renders properly, but the SSR side gives an error about multiple `graphql` instances and the render takes longer than using `HttpLink` with absolute URL:

> As for `async` client components, you might want to use `use` instead, but it will require a split into two components and a suspense boundary to prevent your `clientFactory` from being called all over again:
>
> ```js
> function ParentWrapper({children}){
> const [promise] = useState(clientFactory)
> return {children}
> }
> function ChildWrapper({promise, children}){
> const makeClient = use(promise)
> return {children}
> }
> ```
>
> We can't do that on a library level since it would wrap all our user's applications into an additional suspense boundary and that changes general UX, so it the developer needs to be very aware of that.

Tried the `use` and `useState` thing, it worked but suddenly got this kind of issue, I scanned the lock file, it should only exist a single version of `graphql` in my app, maybe it is creating multiple instances?


_Originally posted by @luchillo17 in https://github.com/apollographql/apollo-client-nextjs/issues/188#issuecomment-1962179974_

Start at ApolloNextAppProvider's makeClient entry point and the SchemaLink path for asynchronously created schemas; reproduce the SSR render using the use/useState wrapper described in the issue. Compare the SSR failure and render behavior with the HttpLink path, then define a fix that avoids duplicate graphql instances without imposing a library-level Suspense boundary.

Written by the indexing model from the issue text.