Idea: a guide for incremental adoption of pothos in a nexus/typegraphql project

Hey @hayes 👋🏼, hope you're doing well.

I'm a member of The Guild, we've been using Pothos for quite some time now and we really admire it but unsurprisingly we get a lot of questions from people asking us about the same thing which is:

> Can I use my Nexus/Typegraphql setup in conjunction with an incremental adoption of Pothos?

It's painful to rewrite an entire production app from one framework to another esp when they differ a lot like Typegraphql -> Pothos migration(I did a Nexus -> Pothos migration recently and it took me a whole painful month to do it). I've started investigating a number of ways we can achieve that and I've got [this minimal example](https://github.com/YassinEldeeb/pothos-incremental-migration-guide) which is a usage of two graphql schema builders that work internally entirely different, my goal is to make that approach as agnostic as possible literally using any graphql framework in conjunction with Pothos. The idea there is that every setup defines its own types and resolvers like:
Typegraphql -> defines `Recipe` object type and its resolver
Pothos -> defines `Person` object type and its resolver

in that particular use case where the two work on their own, it's easy to just use the `mergeSchemas` utility from the `@graphql-tools/schema` package to get a single schema from both at the end before passing it to whatever gql server we're using. The issue is that the nexus/typegraphql/etc.. setup is gonna always have all of application's types and the Pothos setup is gonna always has insufficient types, [an example as in here](https://github.com/YassinEldeeb/pothos-incremental-migration-guide/blob/main/src/pothos.ts#L15) where it gets interesting is when we wanna add a new field to our `People` object type to reference `Recipe` which is in the typegraphql setup, the issue is that even that we're very sure that the `Recipe` object type is gonna exist when the schemas are merged but the Pothos builder isn't aware of that and throws an error because of missing object refs and refuses to build the schema. So the challenge here that I faced is making Pothos not complain about missing types because we know they’re gonna exist when we merge the schemas, so is this a limitation from the `GraphQLSchema` object that gets built or is it a layer that's extensible at Pothos level? because my thinking was towards adding an option for Pothos to skip erroring bc of missing object refs if that's achievable.

Even one of the core engineers for Nexus shared [this thread](https://github.com/graphql-nexus/nexus/issues/1139#issuecomment-1356004051) in which he says that he was very very impressed with the approach of Pothos after playing with it and is also thinking of what we're headed for.

Wanted to share with you this process and get your thoughts on it and hear the possible ways I'm not aware of to support such a behavior/feature.

Start with the linked minimal migration example, especially src/pothos.ts around line 15, and read the issue's references to mergeSchemas and GraphQLSchema. Investigate how Pothos validates missing object references during schema construction. Done means documenting a supported incremental-adoption approach or clearly establishing the required feature and its feasibility.

Written by the indexing model from the issue text.