Mark the old `Microsoft.DSC/PowerShell` and `Microsoft.Windows/WindowsPowerShell` adapters as deprecated

[SteveL-MSFT]

Summary of the new feature / enhancement

Add a warning message when either of these two adapters are used and point to this issue. These adapters have been replaced by the new Microsoft.Adapters/PowerShell and Microsoft.Adapters/WindowsPowerShell adapters as we move away from the nested config model for adapters. Docs need to be updated to use adapted resources directly instead of wrapping them in a nested config.

Basically, users should not use this syntax:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: Use class PowerShell resources
  type: Microsoft.DSC/PowerShell
  properties:
    resources:
    - name: PowerShell 7 Preview
      type: Microsoft.WinGet.DSC/WinGetPackage
      properties:
        Id: Microsoft.PowerShell.Preview

and instead change to:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: PowerShell 7 Preview
  type: Microsoft.WinGet.DSC/WinGetPackage
  properties:
    Id: Microsoft.PowerShell.Preview

Proposed technical implementation details (optional)

Add warning message that these are deprecated in 3.2
Consider formal removal in 4.0 release since this is a breaking change

[michaeltlombardi]

Just to clarify, the deprecated adapters will emit this warning, not the engine, correct?

I'm wondering if there's any value in filing a separate issue for a more general way for resource authors to indicate that their resource (or adapter, or extension) is deprecated, since information to that effect in a manifest would enable DSC and higher order tools to filter deprecated resources and extensions from default view - though to be clear that's a separate issue that would warrant some careful thinking, as it would affect both the CLI and engine.

[SteveL-MSFT]

@michaeltlombardi correct, the change is in the adapter itself to emit the warning.

In the Rust world, a crate would have a semver like 1.1.2+deprecated so we could also have such a convention if we wanted the engine to handle the warning message instead of each resource/adapter/extension.

[theJasonHelmick]

The WG reviewed this - Formal deprecation is to have a deprecationMessage filled in - the semver side is not required

[mimachniak]

This mean that legacy DSC resources base on PowerShell will not rerquired to point on with version of PowerShell will be running ?

[SteveL-MSFT]

This mean that legacy DSC resources base on PowerShell will not rerquired to point on with version of PowerShell will be running ?

Correct. Even now you don't need to explicitly specify the adapter you want to use, but there is a separate feature that was in the last preview, I believe, that allows you to specify the PS7 or WinPS5.1 adapter if that matters. Otherwise, the first adapter found that supports that type will be used.

[Gijsreyn]

This mean that legacy DSC resources base on PowerShell will not rerquired to point on with version of PowerShell will be running ?

Correct. Even now you don't need to explicitly specify the adapter you want to use, but there is a separate feature that was in the last preview, I believe, that allows you to specify the PS7 or WinPS5.1 adapter if that matters. Otherwise, the first adapter found that supports that type will be used.

Gentle reminder that only these adapters didn't shop in the latest preview. You can still test it if you create the manifests manually.