feat: Add support to native Gatekeeper configurations from app values.yaml

[afonsobspinto]

Implemented solution

CloudHarness applications can now supply arbitrary native Gatekeeper proxy.yml settings through their application values:

harness:
  proxy:
    gatekeeper:
      configuration:
        same-site-cookie: "None"
        enable-pkce: true
        max-token-size: 65536
        cors-exposed-headers:
          - X-Request-ID

The configuration uses the native kebab-case property names documented by Gatekeeper, avoiding the need to extend CloudHarness whenever another Gatekeeper option is required.
The effective configuration is built with the following precedence:

1. CloudHarness-generated Gatekeeper settings;
2. global proxy.gatekeeper.configuration;
3. application harness.proxy.gatekeeper.configuration.

Application configuration is therefore the last writer and can override generated or global settings.
The implementation:

• adds configuration: Dict[str, Any] to GatekeeperConf;
• renders the merged configuration consistently for Helm and Compose;
• includes the complete effective Gatekeeper configuration in the Helm Deployment checksum, ensuring pods restart when any option changes;
• preserves the existing TLS safety behavior: an explicitly requested same-site-cookie: None is rendered as Lax when TLS is disabled because browsers require SameSite=None cookies to be Secure;
• updates the CloudHarness Gatekeeper documentation with usage and precedence examples.

This is additive. Existing image, replicas, resources, secret, proxy timeout, and URI-role configuration remain supported.
Individual native Gatekeeper property names and values are not duplicated or validated by CloudHarness.
Gatekeeper remains responsible for validating its native configuration when loading proxy.yml.

Changing the checksum calculation may cause a one-time rolling restart of secured application Gatekeeper pods during the first deployment.

How to test this PR

How to test this PR
Run the model and deployment rendering tests:

pytest -q \
  libraries/models/test/test_deserialize.py \
  tools/deployment-cli-tools/tests/test_helm.py \
  tools/deployment-cli-tools/tests/test_dockercompose.py

The suite verifies:

• arbitrary native configuration values survive model serialization;
• global configuration is inherited;
• application configuration overrides global configuration;
• application configuration can override CloudHarness-generated values;
• Helm and Compose produce equivalent Gatekeeper configuration;
• same-site-cookie: None is retained when TLS is enabled;
• same-site-cookie: None falls back to Lax when TLS is disabled;
• changes to the effective Helm configuration change the pod checksum.

Sanity checks:

• The pull request is explicitly linked to the relevant issue(s)
• The issue is well described: clearly states the problem and the general proposed solution(s)
• In this PR it is explicitly stated how to test the current change
• The issue seta the scope and the type of issue (bug, story, task, etc.)
• The relevant components are indicated in the issue (if any)
• All the automated test checks are passing
• All the linked issues are included in one Sprint
• All the linked issues are in the Review state
• All the linked issues are assigned

Breaking changes (select one):

• The present changes do not change the preexisting api in any way
• This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarness may break after the current update
• This PR and the issue are tagged as alert:deployment

Test coverage (select one):

• Tests for the relevant cases are included in this pr
• The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• The documentation has been updated to match the current changes
• The changes included in this PR are out of the current documentation scope