Removing deprecated APIs

[johannesconsulting]

Description

This PR removed old APIs that are not included in current supported CyberArk version or are removed from documentation.
Its mostly some Gen1 APIs and some APIs that are completely removed.
Doing this cleanup will reduce the codebase and also make it easier for the user to see what parameters can actually be used without being met with errors.
Thinking that most new downloads are using modern supported version of CyberArk and they wont be impacted by these changes.
It makes it a bit easier for us to manage the project too.

I also included a small fix for Set-PASUser. Its currently bugged because the function doesn't send the allowedauthenticationmethods in a array, causing the API to complain if you don't include it.

I tested all the functions manually too, and it worked on 15.0 without issues.

For the sake of transparency, I used assistance from AI for the *.Tests.ps1.
For the actual functions, I did that manually.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that makes existing functionality work differently)
• Documentation update (psPAS website or command help content)
• Other (see description)

How Has This Been Tested?

• Pester test(s) update required
• Pester test(s) updated
• Pester test(s) passing

Test Configuration:

• PowerShell version: 7
• CyberArk PAS version: 15.0
• OS Version: Windows Server 2022

Checklist:

• My code follows the style guidelines of this project
• I have followed the contributing guidelines.
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new test failures or errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have opened & linked a related issue
• I have linked a related issue

[pspete]

I'm not 100% against this, but it will be, I think, the first time support for any API capabilities are removed from the module.
Admittedly, I doubt many people are using any of the older Gen1 APIs, but with it being a breaking change, this is maybe a target for the next Major release (i.e. version 8).
With some of the deviation in API capabilities, I had also been mulling over splitting the module out into Self-Hosted & SaaS flavours....
Rather than dev, perhaps this can be worked on in a separate branch? - conscious it will start to get complex with changes being made for new functionality.

[johannesconsulting]

I agree that this can be saved for a major release.
A separate branch might be a good idea. That can also then include more name changes, maybe support for Pester 6.0+ (all test files needs to be updated I believe?), more cleanups and so on.

Having two seperate modules for SaaS and Self-Hosted might be too soon if I have to give my opinion.
Today they have almost the same APIs except for new features. Until SaaS have vastly different APIs, then a separate module can be justified I believe.