feat(package/cli): Pylon-compatible schema

[vicary]

This may supersedes #2056, adding @kleberbaum as a co-author.

1. Interactive CLI
2. CLI options
3. Add @gqty/pylon with input conversion utilities
4. Tests
5. Changeset

The main goal is to avoid introducing schema changes unless absolutely required.

[vicary]

@kleberbaum In #2056 I can see that params are used as the first parameter instead of the function arguments itself. I would like to hear your thoughts before making my move.

My questions mainly goes around the necessity of exporting { params, return }, let's discuss with exapmles.

# Hypothetical GraphQL schema
type Mutation {
  foo(
    required: String!
    optional: String
  ): String
}

// Pylon implementation
export const graphql = {
  Mutation: {
    foo(required: String, optional?: String) => {
      return `${required}, ${optional}`;
    }
  }
};

Currently GQty generates a mutation schema similar to the section below:

export interface Mutation {
  foo: (args: {
    required: string;
    optional?: string | null;
  }) => ScalarsEnums['String'];
}

As Pylon is built with TypeScript, required parameters must come before optionals. While we may optionally assert this fact during codegen, should it work if the generated schema exports something like this?

export interface Mutation {
  foo: (required: string, optional?: string) => string;
}

If the type above looks good, we can hide the implementation details in a generic converter which reads the generatedSchema object on the fly instead of type *ParamNames.