Code cleanup: bulk removal of deprecated workflow code

[KirkMunro]

PR Summary

Cleanup of workflow code that has been deprecated. In particular:

• deprecation of workflow keyword
• deprecation of parallel keyword (used for parallel activities in workflow)
• deprecation of sequence keyword (used for sequential activities in workflow)
• deprecation of inlinescript activity (used for activities outside of workflow)
• removal of -parallel parameter on foreach statement
• removal of -parallel parameter on switch statement
• removal of related classes/methods
• removal of deprecated resource strings
• updates to non-deprecated resource strings
• removal of the use of "workflow" in many comments

This PR is not exhaustive -- there are still many more references to workflow, particularly in the following files:

• src\System.Management.Automation\gen\EventResource.cs
• src\System.Management.Automation\utils\tracing\TracingGen.cs

Also the following files have a few more references to workflow that I wasn't sure what to do with:

• src\System.Management.Automation\utils\PowerShellETWTracer.cs
• src\System.Management.Automation\utils\PSTelemetryMethods.cs

Comments on those four files and whether or not their references to workflow can be removed would be appreciated.

Beyond those, there will be very few references to workflow, mostly indicating that it's deprecated.

PR Context

See issue #9570.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Yes, but they are approved for removal of workflow functionality (see Can we remove workflow code from PowerShell Core? #9570)
• Experimental features
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

cc: @iSazonov

[iSazonov]

@KirkMunro We have a conclusion to do not remove parallel keyword (for future enhancement of "for -parallel").
As for workflow and sequence keywords in the time I believe we should do the same - to do not remove and inform users with message "unsupported". It is more user friendly than generic parser error message.

[KirkMunro]

We have a conclusion to do not remove parallel keyword (for future enhancement of "for -parallel").
As for workflow and sequence keywords in the time I believe we should do the same - to do not remove and inform users with message "unsupported". It is more user friendly than generic parser error message.

I'm confused @iSazonov, because that seems to contradict what was said in #9570, where the discussion suggests removing them entirely, unless I read it wrong. In that discussion, @SteveL-MSFT said the following:

Part of the reasoning by @PowerShell/powershell-committee to remove is to have the errors at parse time/compile time (for C# code) vs at runtime. There is no plan to ever bring back workflow.

Also there is a difference between the parallel block statement (which was solely a workflow construct) and the -parallel and -throttlelimit (which doesn't appear to be documented btw) parameters on foreach that only worked inside of a workflow. The parallel and sequence block statements are workflow-only, and that has been deprecated, so I believe they should remain removed as per the quote above.

As for foreach and -parallel, that RFC was removed in favor of ForEach-Object -parallel. Do we want a parseable foreach parameter that doesn't work because someday it might be in the foreach statement, or do we want parser errors to catch that it doesn't work, knowing we can implement parallelism support in the foreach keyword if/when we decide to do so, using whatever syntax we want at the time. I prefer the latter. Placeholders are only indicators of how long it actually takes before you do something, and since this is a keyword, there's no risk of conflict with 3rd party extensions, so better to have it result in a parser error as long as it won't work if you ask me.

[KirkMunro]

Also @iSazonov, I did see your comment about the IsWorkflow property on #9570, and agree with your proposal to leave it there as a dummy property for now, updating PowerShellGet so that it will work without IsWorkflow, and then circling back and cleaning up that property. The PowerShellGet update should simply check the PowerShell version, and only use the IsWorkflow property if the PS Version is less than 7. That will allow it to continue to be updated and work across all versions.

[KirkMunro]

@PaulHigin When I saw you log the issue about job debugging, I looked into it because I was curious, and based on my assessment I don't believe that issue has anything to do with removal of workflow functionality.

[KirkMunro]

Also I should call out that a lot of the changes here are just in code comments. There are code changes, sure, but there are a lot of changes in just code comments as well, bulking this up.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this:

• We want to continue to reserve -parallel for foreach and switch so that should stay
• We share concern that we have insufficient test coverage so such a large change may not reveal issues until much later when more people would be impacted

Ask is to split this into smaller pieces that can be reviewed more completely to minimize any risk of regression.

[KirkMunro]

Ok, I'll break it up into chunks.

Also, ignore the most recent change that I just pushed. I just tried something with rebase that I shouldn't have, need to roll that back.

[KirkMunro]

This PR has been superceded by the following PRs, and will be closed.

#10317
#10318
#10319
#10320
#10321
#10326
#10328