[Feature]: Allow New-AzADServicePrincipalAppRoleAssignment to assign an app role to a group or user

### Description of the new feature

### Description

`New-AzADServicePrincipalAppRoleAssignment` only lets you name a service principal as the principal receiving the role. Every parameter set takes `-ServicePrincipalId` or `-ServicePrincipalDisplayName`, so there is no way to assign an app role to a group or a user.

In Graph terms, [`appRoleAssignedTo`](https://learn.microsoft.com/en-us/graph/api/serviceprincipal-post-approleassignedto) accepts a `principalId` that can be a user, a group or a service principal. Az only exposes the service principal case.

Split out from [#17813](https://github.com/Azure/azure-powershell/issues/17813) at the request of @Alex-AZPS, who confirmed this as a gap in [this comment](https://github.com/Azure/azure-powershell/issues/17813#issuecomment-5321404695).

### Why it matters

Assigning an app role to a security group is the normal way to control who can use an application. It's what most tenants actually do, rather than assigning to individual principals. Right now that step can't be scripted with Az, so an otherwise pure Az deployment has to drop out to the Graph SDK for one call.

### Suggestion

Add a `-PrincipalId` parameter (or equivalent) that accepts a user, group or service principal object id, matching what the underlying Graph API already supports.

### Environment

Az.Resources, current version. Same behaviour on Windows PowerShell and PowerShell 7.

### Proposed implementation details (optional)

_No response_

Start at the New-AzADServicePrincipalAppRoleAssignment cmdlet and inspect its existing parameter sets, which currently accept only service-principal recipients. Compare the behavior with the Microsoft Graph appRoleAssignedTo endpoint. Done means the cmdlet accepts a user, group, or service-principal object ID and can assign the app role in Windows PowerShell and PowerShell 7.

Written by the indexing model from the issue text.