fix: ensure `options` are passed to app plugin with `--options` flag

[dhensby]

The TS typings and docs strongly imply that the options object defined in the app.js file should make their way to the app plugin if the --options cli argument is present when running fastify start app.js. This fix does just that, providing the exported options object back to the app plugin when it is registered.

The CLI allows arguments to make their way to the app via additional args (coming after a --), eg: fastify start app.js -l info -- --custom test will populate the plugin options argument with a custom: "test" property. This change deliberately leaves precedence with the CLI args so that the exported options object just forms the default values which can then be overridden as required.

Potential fix to #593

Checklist

• [x] run npm run test ~and npm run benchmark~
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added
• [x] commit message and code follows the Developer's Certification of Origin and the Code of conduct

[dhensby]

It does seem quite deliberate at the moment that these options don't make their way to the plugin and seem to not actually be AppOptions but instead FastifyServerOptions. However, the TS typings definitely set the expectation that the options would be populated from them when using the --options flag.

see the TS template for the (potentially misleading) typings: https://github.com/fastify/fastify-cli/blob/v6.1.1/templates/app-ts/src/app.ts

[dhensby]

Fixed the linting failure, not sure why the tests failed on macos runner - I've tried adding t.end() to the end of the new tests incase that was needed, but otherwise can't see an obvious problem 🤔

[dhensby]

Fixed the linting regression from adding t.end(); 😓

[jsumners]

attn: @fastify/typescript