SqlWindowsFirewall: Change the resource to be more restrictive in firewall openings

Details of the scenario you try and problem that is occurring:
Today the user provides the features (currently supporting SQLEngine, AS, RS and IS) which tells the resource what to open. But this means there is no fine grain in the openings. For example for feature SQLEngine it create rules for the Database Engine executable and SQL Browser service. If it is a default instance, it should be enough to open just the port 1433. If the user also wants to open Browser Service then that should be up to the user, it should not be done automatically. I think the resource should not open ports/application/service if it is not needed, unless user expressively ask to.

Either we can add a new 'Rule' parameter to this resource to which the user can add an array with one or more predefined rules (defined from the article Configuring the Windows Firewall to Allow SQL Server Access).
I had a thought to make the Features parameter deprecated and eventually only have this new 'Rule' parameter. But now I see this new 'Rule' parameter more as a complement to the Features parameter.

We could also, instead of this new 'Rule' parameter, direct the user to do this fine grain openings with the xNetworking resource xFirewall. The only advantage to implement the 'Rule' parameter above is that it "knows" what the service name are called, and in what path the executable exist. If there are port openings, then I think the xNetworking/xFirewall would be better for that.

What do you think?

The DSC configuration that is using the resource (as detailed as possible):
n/a

Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
n/a

Version of the DSC module you're using, or 'dev' if you're using current dev branch:
Dev

Start by reviewing the SqlWindowsFirewall resource and the xNetworking/xFirewall resource named in the issue. Decide whether fine-grained rules belong in a new Rule parameter or should be delegated to xFirewall; done means the resource opens only explicitly requested firewall rules without unnecessary applications, services, or ports.