Adds support for conversion of API manifest document to OpenAI Plugin manifest

[peombwa]

This PR fixes #4 as a prerequisite for microsoft/OpenAPI.NET#1384 by:

• Adds ToOpenAIPluginManifestAsync extension method to a valid instance of ApiManifestDocument. The method uses imported logic from Hidi to generate an OpenAI Plugin manifest.
• Adds tests to validate the conversion.
• Adds CHANGELOG.md.
• Adds Mustafa to CODEOWNERS.

Open Questions:

• Should we allow customers to set openApiFilePath parameter (optional) to ToOpenAIPluginManifestAsync method? openApiFilePath is required to instantiate OpenAI's Plugin manifest API property that points to an API specification (file path or URL). Should we instead default to ApiManifestDocument.ApiDescripionUrl property instead?
• Should the library make web requests to fetch the OpenAPI document that's used to instantiate OpenApiManifest, or should we just expose ToOpenAIPluginManifest method that accepts an instance OpenApiDocument (customer fetches the OpenApiDocument outside the library)?

References

• API Manifest doc.
• OpenAI Plugin manifest doc.
• Existing API manifest to OpenAI Plugin manifest conversion logic in Hidi.

[zengin]

@peombwa
For open questions:

1. I think that the path represents something more general, it gives the impression that the file could also be local. If we are going to support scenarios like that, I think it might be a good idea to keep them separate. But if we are always expected to fetch from the ApiDescriptionUrl in all operations we expose, then not giving the option to specify path makes more sense to me.
2. I think that we can expose both methods, thinking of a scenario where users of library already have an in-memory document object, not fetching could be a minor perf gain.

[baywet]

Thanks for making the changes

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

88.0% Coverage
0.0% Duplication

Added code comment to helper method for clarity.