Is your feature request related to a problem?/Why is this needed
Yes, this feature request addresses a critical limitation in enterprise environments with centralized Private DNS zone management. Currently, when using networkEndpointType: privateEndpoint in Azure File StorageClass, the CSI driver attempts to create Private DNS zones in the same resource group where it creates the Storage Account. This conflicts with enterprise governance policies that require Private DNS zones to be managed centrally in a separate resource group or subscription.

The problem occurs because:

When no resourceGroup is specified, the driver creates both Storage Account and Private DNS zone in the cluster's resource group, but governance policies often prevent DNS resource creation outside designated resource groups
When resourceGroup is specified to point to the centralized Private DNS zone resource group, the driver attempts to create the Storage Account there too, which is undesired
This prevents enterprises from adopting Private Endpoints for Azure Files in AKS clusters while maintaining proper security governance and centralized network management.

Describe the solution you'd like in detail
Add support for separate resource group parameters to distinguish between Storage Account placement and Private DNS zone location:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-file-private-endpoint
provisioner: file.csi.azure.com
parameters:
  networkEndpointType: privateEndpoint
  
  # Storage Account placement (new parameter)
  storageAccountResourceGroup: "rg-aks-cluster"
  
  # Private DNS zone placement (enhanced existing functionality)
  privateDnsResourceGroup: "rg-private-dns-zones" # resource exists already
  privateDNSZoneName: "privatelink.file.core.windows.net" # resource exists already
  
  # Cross-subscription support (new parameter)
  privateDnsSubscriptionId: "12345678-1234-1234-1234-123456789012"

The driver should:

Create Storage Accounts in storageAccountResourceGroup (or cluster RG if not specified)
Use existing Private DNS zones from privateDnsResourceGroup (with cross-subscription support)
Maintain backward compatibility with current resourceGroup parameter behavior

Describe alternatives you've considered
Pre-create Storage Accounts: Use Terraform/ARM to create Storage Accounts beforehand and reference them with storageAccount parameter. This works but adds operational complexity and prevents dynamic provisioning benefits.

Disable governance policies: Not acceptable in enterprise environments as it compromises security and compliance requirements.

Use public endpoints: Defeats the security purpose of Private Endpoints and violates zero-trust network principles.

Manual Private Endpoint creation: Create Private Endpoints manually after Storage Account creation, but this breaks the automation and dynamic provisioning workflow.

Custom CSI driver: Fork and maintain a custom version of the Azure File CSI driver, which adds maintenance overhead and delays security updates.

Additional context
This limitation is particularly problematic in enterprise environments where:

Security teams manage Private DNS zones centrally across multiple subscriptions for hub-and-spoke network architectures
Application teams need autonomy to create Storage Accounts within their own resource groups
Governance policies enforce separation of concerns between networking and storage resources
Compliance requirements mandate centralized DNS management for audit and security purposes
The feature would enable proper enterprise adoption of Azure Files with Private Endpoints in AKS while maintaining security governance and operational best practices. This pattern is already supported in other Azure services and CSI drivers, making it a natural extension for the Azure File CSI driver.