feat: add support for AsyncAPI headers

[matthew-inamdar]

Description

This PR adds opt-in support for header schemas in AsyncAPI specifications.

The ProcessorOptions type now accepts a new AsyncAPIInputProcessorOptions type for the asyncapi field.

The AsyncAPIInputProcessorOptions type has a single boolean option for includeMessageHeaders.

When includeMessageHeaders is set to true the following logic applies:

1. During AsyncAPI traversal, models are generated for headers along with the existing logic of payloads.
2. For operations with multiple messages:
   1. The payload union model name is suffixed with Payload
   2. The header union model is added and suffixed with Headers

N.B. I expect both the change in behavior for 2.i., and also the suffix naming convention to possibly be contentious and are therefore looking for guidance on these approaches.

Related Issue

#2482

Checklist

• The code follows the project's coding standards and is properly linted (npm run lint).
• Tests have been added or updated to cover the changes.
• Documentation has been updated to reflect the changes.
• All tests pass successfully locally.(npm run test).

Additional Notes

There is a further consideration about having a type generated for each message which is composed of headers and payload types – this would allow for discriminating once for the entire message instead of separately for both the headers and the payload.

This seems to require further changes to the behavior and I'm not confident if there is an appetite for it. If there is, I'll be happy to look into this approach.

[netlify]

❌ Deploy Preview for modelina failed.

Name	Link
🔨 Latest commit	fd1ceae
🔍 Latest deploy log	https://app.netlify.com/projects/modelina/deploys/69b1440a09b01100087773bd

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud