Decide on a new organizational structure for types

[CodeProKid]

We need to decide on a new organizational structure for types. I recommended the following:

Within the Types folder, I think it would be good to have an Input folder and an Objects folder. We would then put all of the classes for query args in the Input folder, and the classes for object return values in the Objects folder. I think this naming convention most closely mimics the classes those classes are actually extending, but I could be open to something like "Input" and "Output" if you preferred that. I think this would really help clean up that folder since it's a little confusing what each of those classes is doing until you really dive into them. We could then put the RootQueryType in the root of the Types folder since that is different than everything else in there.

Then @jasonbahl came back with the structure from here: https://github.com/ParabolInc/action/tree/master/src/server/graphql/models

he said:

so, re structure. . .that's one thing I keep going back and forth on. . .it's hard to find any large open source examples of how folks are structuring. . .I think the largest example of an open source GraphQL server that I know of is: "Action" a Jira/Trello-esque app. . .here's how they structure their "types"

I don't think it matters which way we go, we just need to do something to organize the types.

[CodeProKid]

Let's try and go with this pattern, for now, where all the pieces relating to a specific Type are organized together. This should provide a more scalable pattern for plugin & theme developers to follow if/when folks start defining their own GraphQL Schemas for Types their code provides:

/Type/User
/Type/User/UserType
/Type/User/UserQuery
/Type/User/UserMutation
/Type/User/Connection
/Type/User/Connection/UserConnectionArgs
/Type/User/Connection/UserConnectionDefinition
/Type/User/Connection/UserConnectionResolver