fix: add workflow flow actions to decomposed workflow preset and allow isAddressable

[mcarvin8]

What does this PR do?

Updates the decomposed workflow preset to add the child type: Workflow Flow Actions

In the current decomposed preset, Workflow Flow Actions are added to the *.workflow-meta.xml file instead of decomposed into their own directory and smaller files.

This is causing issues deploying decomposed workflow children, as Salesforce CLI appears to check the *.workflow-meta.xml file even when deploying just 1 decomposed workflow child like an email alert. Since the *.workflow-meta.xml isn't "empty", I'm unable to deploy just a decomposed WorkflowAlert for example.

Also, the "isAddressable: false" key in each supported decomposed workflow child is preventing each decomposed workflow child from being retrieved or deployed without the parent.

After working with @shetzel via CLI Issue 2563, updating the preset to remove all isAddressable: false lines and manually add workflow flow actions to the preset fixes my issue retrieving and deploying decomposed workflow children. I've tested this out in my work's repo, which has tons of workflows with workflow flow actions.

Let me know if your team wants to make this a beta2 instead of modfying an existing beta. Since I'm not changing the overall decomposed workflow structure, just adding a missing child and fixing the addressable feature, I think it makes sense to me to just update the beta preset.

What issues does this PR fix or reference?

forcedotcom/cli#2563

Functionality Before

Decomposed workflow children besides Flow Actions are decomposed into their own sub-directories and files.

Flow actions are added directly to the *.workflow-meta.xml files.

Retrieves can work but deployments fail because it's seeing the Flow Action in the *.workflow-meta.xml file and isAddressable is false, so I can't deploy the child without the parent file.

Functionality After

All decomposed workflow children including Flow Actions are decomposed into their own sub-directories and files.

The *.workflow-meta.xml file just contains the workflow header/footer.

Retrieving and deploying individual workflow children including Flow Actions works with Salesforce CLI.

[BluecanvasReen]

By coincidence I have been debugging this problem for the last couple of days. The same problem happens for SharingRules.

The normal registry, does not correctly detect the fullname of the components, because it does not contain the correct strategy, and the beta version does not work because of isAddressable === false.

Added this comment to get notifications, but happy to support this issue if need be.

[mcarvin8]

You can work around the isAddressable issue @BluecanvasReen if you copy the existing preset into your sfdx-project.json file in a key named registryCustomizations and remove all "isAddressable": false, lines. Then you would need to temporarily remove the existing preset in sourceBehaviorOptions.

I have my sfdx-project.json with the updated workflow preset in forcedotcom/cli#2563 you can reference.

Obviously the long-term fix is for Salesforce to fix the beta preset with a new CLI build, but doing this with workflows was able to get me un-blocked in my work's repo.

I'd like to get a Salesforce engineer to respond to this PR first, but I can update this PR to fix the sharing rules preset if they concur with this fix.