feat(package/cli): Pylon-compatible schema

[vicary]

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

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

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

[github-actions[bot]]

🚀 Snapshot Release (canary)

The latest changes of this PR are available as canary on npm (based on the declared changesets):

Package	Version	Info
@gqty/cli	4.3.0-canary-20250223094634.f33b2a59894aa59019b5ce49acb38087a48b9e4c	npm ↗︎ unpkg ↗︎

[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.