Cleanup alias and missing SafeCommands

[fflaten]

PR Summary

• Cleanup all code in /src/* to avoid usage of alias (related Pester crashes if user does not have alias foreach defined #1740)
• Adds missing $SafeCommands['xxxx'] on external function-calls in /src/*
• Adds a PSScriptAnalyzer configuration with initial rules. Should be tuned later if it's going to be used in CI.
• Adds a custom PSScriptAnalyzer module for build-rules. Only rule atm. is looking for external function-calls that should use $SafeCommands (defined in the dictionary)

PR Checklist

• PR has meaningful title
• Summary describes changes
• PR is ready to be merged
  • If not, use the arrow next to Create Pull Request to mark it as a draft. PR can be marked Ready for review when it's ready.
• All tests pass
  • Run ./build.ps1 -Clean; ./test.ps1 -NoBuild. Use a new PowerShell process when C# code is changed.
• [NA] Tests are added/update (if required)
• [NA] Documentation is updated/added (if required)
  • Should be added for PSSA in the future, but not mandatory or part of CI yet. Rule documented in comment-based help

[nohwnd]

Not part of this change, but if you want to come up with a rule that forces us to not use New-Object, Where-Object, Select-Object and ForEach-Object at all it would be nice to have that in a Draft PR. Those cmdlets are much slower than their normal counter parts. I don't have good replacement for some of the usages (as you saw with the Select-Object -First), but this analyzer rule would allow me to find all of them and fix them. We can probably replace Select-Object -First with call to .NET method that uses Linq. New-Object I already replace with Pester Factory where I create types using .NET constructor.

[fflaten]

After this cleanup, a simple search for e.g. (?:new|foreach|select|where)-object will show all, but a rule could be used for in-editor syntax highlight I guess. Could look into it as a warning rule (no autofix-support). 👍

If support for PSv3 was dropped then .Foreach() and .Where() could've been used. Select-Option needs a custom function-replacement I guess.

[fflaten]

sort is mapped to application in unix. Also found that some rules like PSUseSingularNouns don't run in unix, so note to self: Run PSSA in Windows or both.

[nohwnd]

sort is mapped to application in unix.

That is definitely not expected, Sort-Object should be used in all cases.

[nohwnd]

After this cleanup, a simple search for e.g. (?:new|foreach|select|where)-object will show all, but a rule could be used for in-editor syntax highlight I guess. Could look into it as a warning rule (no autofix-support). 👍

No pressure, it was just an idea. I should first get my profiler to work properly and start measuring (if only on PS5.1 because that is the only place where it currently works).

If support for PSv3 was dropped then .Foreach() and .Where() could've been used. Select-Option needs a custom function-replacement I guess.

Having v3 support is important because people still write modules that are compatible down to v3, so they should be able to test them easily.

[fflaten]

sort is mapped to application in unix.

That is definitely not expected, Sort-Object should be used in all cases.

Yup. Could have given some different results on unix vs windows. Fixed now.

Looks like the CI failure on PSv3 and v4 was caused by me removing one BOM too many in Mock.ps1. PSSA auto-fix added BOM, so had to remove manually, but didn't notice that Mock.ps1 had it originally. Non-consistent use of BOM by design or new issue?

[nohwnd]

Non-consistent use of BOM by design or new issue?

New issue.