CRDs need updates to accommodate authorizer-plugin support

Problem Statement

Pull request #3110 adds support for pluggable authorizers. One remaining gap is the presence of Cedar-isms in the CRDs. For example:

https://github.com/stacklok/toolhive/blob/c973cdc2a88dc7b2c0c3e33f65bb1eade39345e5/deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_mcpservers.yaml#L93

There are a few ways to handle this, but they all likely require a new version of the affected CRDs:

Possible Solutions

1. New CRD schema drops "inline" authz support, relying purely on a configmap-reference. Validation would remain at the code level but would be removed from the schema level.
2. New CRD schema modifies "inline" authz support to relax schema checking (see https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#controlling-pruning) to accommodate various types of authz plugins. Validation would remain at the code level, but is removed at the schema level
3. We drop "configmap-reference" support and create CRD(s) for Authz configuration. The inline configuration would be generalized to accept an inline representation of the Authz configuration using RawExtensions. Likewise, the previous use cases for configmap-based Authz configuration would now use the new Authz CRD. Validation would remain at the code and inline schema levels, and is now also introduced at the "external reference" level, since we've replaced ConfigMaps with a CRD.

Start with deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_mcpservers.yaml and review PR #3110 for the pluggable-authorizer changes. Compare the affected CRD schemas with the three proposed approaches, then confirm the design with maintainers before updating the CRD version and related manifests. Done means the affected CRDs accommodate authorizer-plugin configuration without retaining incompatible Cedar-specific schema assumptions.