[Feature request] Allow users to configure denied actions instead of allowed actions in the deny assignments created

**Is your feature request related to a problem? Please describe.**
Currently, the deny assignments created by deployment stacks works as a whitelist. All actions except read are denied by default and we are then able to configure specific actions that can be executed through the switch `-DenySettingsExcludedAction`.

However, according to the documentation, it is possible for deny assignments to work as a blocklist, where only specific actions are blocked by the assignment.

The issue with the current deny assignments is that, when only a small set of actions should be blocked, the excluded actions to add can be quite high considering that some providers can have over a hundred actions attached to them.

It also take a lot of time to read and understand all the actions in a specific provider to exclude all that are not meant to be blocked.

This situation would be solved by being able to only specify actions that need to be blocked by the deny assignment generated.

**Describe the solution you'd like**
A new option to the `DenySettingsMode` that would turn the deny assignments configuration from a "denyX" to "allow the provided actions". These allowed actions would be provided to a new switch (ie: `-DenySettingsBlockedActions`).

EDIT: Or allow to specify both blocked and excluded actions. For example:
`DenySettingsMode` to `UserProvided`

`DenySettingsBlockedActions` to :
- "Microsoft.Authorization/*"
- - "Microsoft.Storage/*/read"

`DenySettingsExcludedActions` to:
- "Microsoft.Authorization/*/read"

**Describe alternatives you've considered**
Breaking the stack into smaller stacks. But this implies breaking down the bicep/ARM file down and passing outputs around several different deployments.

**Additional context**
Imagine a web app deployed with an APIM subscription, API and policies. I may allow anyone with the contributor role to modify the app settings of the app, modify the API logging settings, ... for quick troubleshooting, but I absolutely do not want anyone except a few allowed individuals to retrieve the subscription key and modify the API policy.

If I want to do that through excluded actions, I would need to add well over a hundred of excluded actions.

If I want to split the stack and only deploy the subscription key and policy in it, I'll still need to exclude everything not related to modifying the policy or listing the subscription key secrets.

With the ability to set specific actions to be denied, I only need to pass:

1. `Microsoft.ApiManagement/service/subscriptions/listSecrets/action`
2. `Microsoft.ApiManagement/service/tenants/apis/operations/policies/write`

To the new switch and I have blocked everything I need to block