Add azure_rm_cognitiveservicesdeployment and _info modules

[p3ck]

SUMMARY

Adds two new modules to manage Azure OpenAI / Azure AI (Cognitive Services) model
deployments, addressing the deployment half of the "Automate Generative AI with
Azure OpenAI" work:

• azure_rm_cognitiveservicesdeployment — create, update, and delete a model
  deployment within a Cognitive Services / Azure OpenAI account. Idempotent and
  supports check mode.
• azure_rm_cognitiveservicesdeployment_info — get a specific deployment or list
  all deployments in an account.

The top-level account is already fully managed by azure_rm_cognitiveservicesaccount
(kind: OpenAI, sku, network rules, custom subdomain, tags), so no new account
module is introduced; an Azure OpenAI EXAMPLES block is added there to document
the end-to-end workflow.

Implementation notes:

• These are management-plane (ARM) resources, reached via the existing
  cognitive_services_management_client.deployments operations.
• begin_create_or_update is a PUT (full replace), so on update the module carries
  forward the existing model/sku the user did not resupply, and compares desired
  state against a copy (so default_compare's in-place mutation cannot leak
  read-only fields such as provisioning_state into the PUT body).
• model is required only when creating a deployment.

Live integration was validated in eastus (create, idempotent re-run, info
get/list, capacity update, delete, idempotent delete; all assertions passed) using
a GenerallyAvailable model so the test is not broken by model-version deprecation.

ISSUE TYPE

New Module Pull Request

COMPONENT NAME

azure_rm_cognitiveservicesdeployment
azure_rm_cognitiveservicesdeployment_info

ADDITIONAL INFORMATION

The CI service principal needs permission to create Azure OpenAI accounts and
model deployments (OpenAI quota in the test subscription/region).

Assisted-by: Claude Opus 4.8 (Anthropic)

[zunyangc]

Hi @p3ck, thanks for the PR, small change needed.

[zunyangc]

_merge_for_update only keeps the existing model and sku. Update is a full-replace PUT, so changing capacity without repeating these settings resets them. Consider carry forward every writable property.

[p3ck]

Good catch, thanks — fixed in 40a6cd01.

_merge_for_update now carries forward every writable property the user did not resupply, not just model/sku. It copies all existing properties except the SDK's read-only fields (provisioning_state, capabilities, call_rate_limit, rate_limits, dynamic_throttling_enabled, and current_capacity), plus sku/tags. So a capacity-only update no longer resets rai_policy_name, version_upgrade_option, etc.

I also strengthened the integration test to prove it: it now creates the deployment with a non-default version_upgrade_option: NoAutoUpgrade, then updates only the capacity and asserts model and version_upgrade_option survive the PUT. Live run in eastus passes (ok=24 failed=0); the update response shows capacity: 2 with version_upgrade_option still NoAutoUpgrade.

Note begin_update (PATCH) can't be used as an alternative here — its body is PatchResourceTagsAndSku, so it only supports tags/sku, not model/rai_policy_name/version_upgrade_option.