Add interface declarations to PowerShell to support DSC Resource authoring

[michaeltlombardi]

As an engineer developing and maintaining DSC Resources, I want to be able to define an interface for broad types of DSC Resources in my module and ensure that my implementations match that interface without having to add C# development to my workflow or rely on using Add-Type to define an interface in a string (which raises problems around testing and documentation).

Being able to define interfaces in PowerShell similar to how I can define classes and enums should enable me to quickly define an enforceable standard for my resources. For example, if I am writing DSC Resources for my organization and we want to avoid specifying credentials and rely instead on retrieving secrets from a store, I would like to be able to define an interface that identifies a DSC Resource as using that pattern and provide engineers in my organization with the information they need to know how to implement that for a resource.

Ideally, interfaces would be able to have default implementations, which would further reduce the work needed by people using them.

Context

Several of the DSC Community modules implement base classes that contain only methods with default implementations. For example, DnsServerDsc, AzureDevOpsDsc, and JeaDsc.

While these modules are using classes to define these methods for actual DSC Resources to inherit from, these are more correctly (I think) interfaces with default implementations (especially as they do not have any properties).

Aside:
While my impetus for this feature is specific to DSC Resource authoring, I do think it more broadly valuable to PowerShell developers in general. Interfaces are a useful tool and unavailable to PowerShell developers without moving into C#.

Proposal

I propose that PowerShell be extended to enable defining interfaces in PowerShell without requiring the use of Add-Type or a binary module. As only properties and methods are supported for PowerShell classes, I think the same limitations applying to interfaces makes sense as well. As C# supports default implementations for interfaces, so should the PowerShell syntax.

This is a complex feature to implement but one we're already seeing workaround patterns for in the community.

There is prior art for this feature (see PowerShell/PowerShell#2223, PowerShell/PowerShell-RFC#152, and this branch by @IISResetMe).