RFE: Open up WASM config API for arbitrary external authorization services

## Overview

Currently, the `wasm-shim` config API strongly assumes Authorino when dealing with `ServiceType::Auth`. We should open up the `wasm-shim` configuration API to easily configure and route to arbitrary external authorization services.

## Use Case

I'm hoping to implement `AccessPolicy` as a metapolicy using the Kuadrant Policy Extensions SDK. In this model:
- **Inline authz rules** naturally translate to `AuthPolicy` (which works perfectly with the current `wasm-shim` Authorino integration).
- **ExternalAuth rules** need to translate to additional configuration pushed down to the `wasm-shim`, instructing it to call out to a completely different, user-defined external authorization service.

## The Problem

Right now, utilizing `ServiceType::Auth` triggers legacy translation (`legacy_translation::auth`) that hardcodes the `envoy.service.auth.v3.CheckRequest` message construction. This translation makes specific assumptions about metadata contexts and context extensions (`host: scope`) that are highly tailored for Authorino.

While `wasm-shim` does provide a `ServiceType::Dynamic` and `TypedAction`s (with `GrpcOperation`) that allow for arbitrary gRPC calls via CEL `messageBuilder`s, requiring the control plane to manually construct a full `envoy.service.auth.v3.CheckRequest` via CEL for every `ExternalAuth` rule is cumbersome and error-prone.

## Proposed Solution / Enhancement

We should enhance the `wasm-shim` configuration API to treat arbitrary external authorization as a first-class citizen. Potential approaches include:

1. **Decoupling `ServiceType::Auth` from Authorino assumptions:**
- Introduce a more generic `ServiceType::ExtAuth` (or generalize `Auth`).
- Provide a simplified configuration block (similar to Envoy's standard `ext_authz` HTTP filter) that allows configuring which headers to pass, whether to include the body, etc., without manually writing a massive CEL `messageBuilder`.

2. **Native Payload Builders for Standard Interfaces:**
- If we stick to `TypedAction`s and `Dynamic` services for `ExternalAuth`, the `wasm-shim` could provide built-in CEL macros or simplified builders for the `CheckRequest` payload to avoid massive inline CEL strings generated by the control plane.

3. **Response Handling:**
- Ensure that the configuration allows mapping the response from an arbitrary `ExtAuth` service gracefully (e.g., propagating dynamic headers from the auth service to the upstream request, or handling specific HTTP status codes on denial).

## Acceptance Criteria
- `wasm-shim` configuration schema supports defining an external auth service without Authorino-specific metadata formatting.
- `AccessPolicy` metapolicy translations can push `ExternalAuth` configurations directly to the `wasm-shim` without complex workarounds.
- Documentation or examples demonstrating how to configure a non-Authorino external auth service.

Start with the wasm-shim configuration API, especially ServiceType::Auth, ServiceType::Dynamic, TypedActions, GrpcOperation, and legacy_translation::auth. Define how arbitrary external authorization avoids Authorino-specific metadata, supports request and response handling, and can be documented with a non-Authorino example; done means all three acceptance criteria are met.

Written by the indexing model from the issue text.