feat: Add SecureString support to Get-D365LcsApiToken -Password param

[pavankadabala-png]

Closes #673

What this changes

-Password previously accepted [string], which triggered the PSAvoidUsingPlainTextForPassword analyzer rule and exposed credentials in plain text in memory. This PR changes it to [securestring] while preserving full backward compatibility.

How it works

SecureStringTransformAttribute class (new, defined above the function):
A custom ArgumentTransformationAttribute that intercepts the -Password binding. If a plain [string] is passed, it silently converts it to a [securestring] via ConvertTo-SecureString. If a [securestring] is already provided, it passes through unchanged. This means no existing scripts need to be updated.

Plaintext recovery before Invoke-PasswordGrant:
The OAuth grant flow still requires a plaintext credential. One line converts the SecureString back to plaintext just before the call using the standard [System.Net.NetworkCredential] idiom, which is the accepted safe pattern for this scenario:

$plainTextPassword = [System.Net.NetworkCredential]::new("", $Password).Password

Summary of changes

• Add SecureStringTransformAttribute class above the function
• Change -Password type from [string] to [securestring], decorated with [SecureStringTransform()]
• Add $plainTextPassword conversion line; pass it to Invoke-PasswordGrant instead of $Password
• Remove PSAvoidUsingPlainTextForPassword suppression (no longer needed)
• Update .PARAMETER Password CBH to document dual-type support
• Add new .EXAMPLE showing Read-Host -AsSecureString usage

Backward compatibility

No breaking changes. Callers using -Password "plaintext" continue to work identically — the argument transform handles the conversion transparently before PowerShell binds the parameter.

[FH-Inway]

When I first tested this, I got the following error:

Error: Cannot find the type for custom attribute 'SecureStringTransform'. Make sure that the assembly that contains this type is loaded.

After changing the name of the attribute to SecureStringTransformAttribute, it started working - not sure why the Attribute part is needed here, normally it can be dropped.

After that, it turned out that the approach is incompatible with the unit testing framework Pester. We use that to run all kinds of tests against the functions. One of them validates the examples from the function documentation. This is not a full functional test. Instead, Pester creates a mock of the function and then validates that the command itself is valid. Unfortunately, the way the mock is created does not support custom attributes (see pester/Pester#1772 for a related issue).

So I excluded Get-D365LcsApiToken from the generic example tests and wrote a custom test script for it.

Note I also rebased on the latest master to include the fixes for the default values of mandatory parameters.

I created pr pavankadabala-png#2 for those changes, targeting your feature branch. Note it currently says there is a conflict. You can ignore that and reset your branch to the tip of my branch. Afterwards, the checks for this pull request should be successful.

[Splaxi]

There is a typo:

enhvironment