Too many fields in additionalTypeDefs will cause an `- ENAMETOOLONG: name too long, stat ` error

Hi there,
I have encountered an issue that might be an edge case but I'll try to detail the steps to reproduce it.

I was using an inline string in my `additionalTypeDefs` ( https://developer.adobe.com/graphql-mesh-gateway/mesh/advanced/extend/#extending-graphql-schema-with-additionaltypedefs ) and over several weeks of development the string grew quite large as many fields were added:

`\n type MyAddress { name_1: String \n ... } type MyCompany { customer_name: [MyAddress] [...many more] `

Once the inline string because excessively long the mesh started reporting:

` - ENAMETOOLONG: name too long, stat '/usr/src/node-app/{MYMESHID}/`

To solve this (which I suspect was due to how the string is being treated by the meshing process) I decided to move the schema definition and use a file pointer (which is not in the devdocs but by inference of `additionalResolvers` I thought it might be possible):

` additionalTypeDefs: "./graphql/placeholder.graphql" `

However after copying the inline content and ensuring valid GraphQL syntax removing the "\n"s and so on I got a:

```
💥 🕸️ Mesh Error:
Unable to find any GraphQL type definitions for the following pointers:

- ./graphql-schemas/extend.graphql

at prepareResult (/usr/src/node-app/node_modules/@graphql-tools/load/cjs/load-typedefs.js:93:15)
at loadTypedefs (/usr/src/node-app/node_modules/@graphql-tools/load/cjs/load-typedefs.js:43:20)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at async resolveAdditionalTypeDefs (/usr/src/node-app/node_modules/@graphql-mesh/config/cjs/utils.js:59:25)
at async Promise.all (index 3)
at async processConfig (/usr/src/node-app/node_modules/@graphql-mesh/config/cjs/process.js:88:114)
at async Object.handler (/usr/src/node-app/node_modules/@graphql-mesh/cli/cjs/index.js:297:32)
```

Googling led me to this: https://github.com/dotansimha/graphql-code-generator/issues/2979

and based on that issue I added a dummy query operation for my types just to make the generation fine but that also did not work; it didn't work either in the same .graphql or adding it to an array and then to the typeDefs, i.e.:

`
"additionalTypeDefs": [
"./graphql/placeholder.graphql",
"./graphql/operation.grapqhl"
]
`

As a workaround, I experimented with splitting my large inline string into in array:

`
"additionalTypeDefs": [
"\n type FirstType { ... } ( long line )",
"\n type SecondType { ... } ( long line )",
]
`

and that did the trick, but I wonder if that's right and it would work properly (I'm in the process of testing it)

Could the handling of file pointers for additionalTypeDefs be investigated? Ideally, I'd like to store there my extend data so that I don't have to maintain a very long string with a plethora of "\n" which is prone to errors (which can't even be too long or will error out in any case ;( )

My `@adobe/aio-cli-plugin-api-mesh` version is 5.2.3

Thanks,
Nello

Start with the additionalTypeDefs configuration and the resolveAdditionalTypeDefs entry point shown in @graphql-mesh/config/cjs/utils.js. Reproduce both the oversized inline string and the ./graphql/placeholder.graphql pointer, then trace how each is interpreted. Done means valid file-based type definitions load successfully without ENAMETOOLONG or the unable-to-find-type-definitions error.

Scritto dal modello di indicizzazione a partire dal testo della issue.