Add Radius.Dapr/stateStores

[SoTrx]

Hey guys,

This PR introduces the initial implementation of the Dapr RP using UDT.

---

Description

• Added the Dapr.stateStores resource type (in both Bicep and Terraform).
• Enabled running multiple tests for a single resource type. (This can be reverted if needed.)
• Excluded Bicep files under /modules/ from validation to allow file reuse (e.g., shared type definitions) across Dapr modules. (This can also be reverted if needed.)
• Added a ClusterRole to allow the Terraform identity to manage Dapr components and list CRDs (required by the kube_manifest Terraform resource).
• Installed the Dapr CLI during dev cluster creation.

Related GitHub Issue: Discussed externally

---

Testing

This PR includes two tests using the same approach as the previous Dapr implementation:

1. Using the default state store created in the recipe (Redis).
2. Using a manually created state store.

Once the Radius.Dapr/secretStores type is implemented, an additional test should be added using a secret store.

Both current tests use a readiness check on the backend container to ensure the Dapr components are properly initialized.

Contributor Checklist

• File names follow naming conventions and folder structure
• Platform engineer documentation is in README.md
• Developer documentation is the top-level description property
• Example of defining the Resource Type is in the developer documentation
• Example of using the Resource Type with a Container is in the developer documentation
• Verified the output of rad resource-type show is correct
• All properties in the Resource Type definition have clear descriptions
• Enum properties have values defined in enum: []
• Required properties are listed in required: [] for every object property (not just the top-level properties)
• Properties about the deployed resource, such as connection strings, are defined as read-only properties and are marked as readOnly: true
• Recipes include a results output variable with all read-only properties set
• Environment-specific parameters, such as a vnet ID, are exposed for platform engineers to set in the Environment
• Recipes use the Recipe context object when possible
• Recipes are provided for at least one platform
• Recipes handle secrets securely
• Recipes are idempotent
• Resource types and recipes were tested