feat: query composer as extension

[jasonbahl]

This PR demonstrates that 3rd party plugins cannot be added and access state from Graph_i_QL because of the structure of GraphiQL and the reliance on GraphiQL Context providers, etc.

in the legacy WPGraphQL IDE, we had our own context provider that maintained the Query and Schema and passed it down to GraphiQL and the Query Composer (which was not a child of GraphiQL).

But in the new GraphiQL, the "plugins" are expected to be children of and access state from GraphiQL.

This pattern doesn't lend well to what we're trying to do by having plugins enqueued from third parties and access the same state.

This relates to why we need redux in the first place. . .and why Gutenberg adopted redux (see: #47, #41)

Anyway, right now I don't see a path forward that allows 3rd parties to hook in and do anything meaningful because they can't access state unless they're truly a child of the larger GraphiQL component.

Hopefully I'm wrong and you can prove there's another way? 🤞🏻

I think the path forward, in my eyes, is to lift all the state that GraphiQL maintains (Schema, Query, isFetching, tabs, etc) into the redux store, then re-construct GraphiQL with the same components, but with state from Redux.

This would allow 3rd party components (i.e. composer, faust extensions, etc) to access the state and do something with it.

---

for context, this is a screenshot of the IDE after you click on the "Explorer" extension.

[jasonbahl]

related #79
related #78
related #5

[jasonbahl]

closing as this was a POC to show the complications of the current architecture and demonstrate why we will ultimately need to re-factor to make things available on the window so that 3rd party plugins can interact with other pieces of the application. (see #81)