Adding custom attribute to the openAPI endpoints possible?

**Describe the issue**
I am building a .NET 8 out-of-process azure function and I have added the openAPI extensions. Everything mostly works great.
My only issue is that I am using a custom authentication middleware (no choice, external factors). I need to add an extra attribute to the openAPI Endpoints so this middleware knows to ignore these endpoints. Basically an custom "Allow-anonymous".

But I cannot find the place to do this.
I found https://github.com/Azure/azure-functions-openapi-extension/blob/main/templates/OpenApiHttpTrigger.cs.
But when I put a variant of that in my project I get errors on startup that the openapi functionname have been declare twice. From the code repo I cannot figure out how, if at all, DefaultOpenApiHttpTrigger and derivatives are used.

Basically I would like to do somthing like this:

```
///
/// Invokes the HTTP trigger endpoint to get OpenAPI document.
///
/// instance.
/// OpenAPI document spec version. This MUST be either "v2" or "v3".
/// File extension representing the document format. This MUST be either "json" or "yaml".
/// instance.
/// OpenAPI document in a format of either JSON or YAML.
[Function(nameof(OpenApiHttpTrigger.RenderOpenApiDocument))]
[OpenApiIgnore]
----> [AllowAnonymous] <----
public new async Task RenderOpenApiDocument(
[HttpTrigger(AuthorizationLevel.Function, "GET", Route = "openapi/{version}.{extension}")] HttpRequestData req,
string version,
string extension,
FunctionContext ctx)
{
var response = await this.Function.RenderOpenApiDocument(req, version, extension, ctx).ConfigureAwait(false);

return response;
}
```

Is this possible?

I can also check in the middleware for the swagger endpoints entrypoints and filter on that, but that feels a little more crude to me.

Start with templates/OpenApiHttpTrigger.cs and trace DefaultOpenApiHttpTrigger and its derivatives to understand how the built-in OpenAPI functions are registered. Reproduce the startup duplicate-function error with the shown override approach, then determine whether a custom attribute can be attached without duplicate registration; done means a supported customization path or documented limitation.

Written by the indexing model from the issue text.