Allow more enum configs in client-preset

[jthoward64]

The client-preset package restricts the allowed configs to improve developer experience, however in monorepo environments it is important that some things work the same across the board. A big example of this is enums, notably having enums defined as const and being able to reuse any enums that are shared between client and server

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.

Description

The client-preset package restricts the allowed configs to improve developer experience, however in monorepo environments it is important that some things work the same across the board. A big example of this is enums, notably having enums defined as const and being able to reuse any enums that are shared between client and server.

This PR does exactly that, allows passing enumsAsConst and enumValues to the underlying plugin.

Related # (issue)

#8993

Type of change

Please delete options that are not relevant.

• [x] New feature (non-breaking change which adds functionality)

Screenshots/Sandbox (if appropriate/relevant):

N/A

How Has This Been Tested?

Literally just add the config options and see the change, I have been using these fields in @ukdanceblue/monorepo for almost a year now without issue.

Test Environment:

• OS: Windows or Linux
• @graphql-codegen/...: client-preset
• NodeJS: 18,20,22

Checklist:

• [x] I have followed the CONTRIBUTING doc and the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules

Further comments

N/A