feature: Allow the specification of request-time model API keys via request headers

Did you check the docs?

• I have read all the NeMo-Guardrails docs

Is your feature request related to a problem? Please describe.

Right now, there's no way that I can see to pass request-time API keys to the NeMo Guardrails server. That means the deployer of the server must always use their own API key to authenticate to any downstream LLMs, instead of the caller's API key. This makes user usage tracking on the downstream LLMs very difficult.

Describe the solution you'd like

Some mechanism to pass user API keys through the NeMo Guardrails server to the downstream LLMs, at least for /v1/chat/completions models.

Ideally, this would allow the specification of an auth header in the inbound request to the server that gets translated into an "Authorization: Bearer xyz header when making the LLM server request, e.g.:

models:
  - type: main
    engine: openai
    model: gpt-4
    api_key_header: "X-API-User-Key"  # The name of the HTTP header containing the API key
    parameters:
        openai_api_key: 'deployer-key'

Then, any inbound request:

• with a header X-API-User-Key: $something will send Authorization: Bearer $something
• without a matching header will send Authorization: Bearer $deployer-key

This provides a a number of benefits versus recycling the inbound Authorization header:

1. We don't need to enforce that the authentication key to the NeMo Server matches the authentication key to the model
2. We can set openai_api_key to something like invalid_token to enforce that only authenticated users can access the model, without having to provide unfettered access via the deployer's token.

Describe alternatives you've considered

1. Redeploying an instance of the server for each new user token <- this is obviously a bad approach

Additional context

No response

Start at the server's /v1/chat/completions request handling and trace how the YAML models configuration reaches downstream LLM requests. Define the header-to-Authorization fallback behavior described in the issue, including requests without the configured header, and verify that the deployer key remains the fallback.