Add the Deletion Process to the Editorial Workflow

This request is related to:
- https://github.com/decaporg/decap-cms/issues/5650
- https://github.com/decaporg/decap-cms/issues/6610

**Is your feature request related to a problem? Please describe.**

TL;DR: The problem is that making changes and releasing changes are two different things, which are identical in the current Delete workflow.

In our use case, we have a committee that uses Decap to work on proposed changes to a file, which are then presented to another body that makes the actual decision to accept or reject those PRs. We use the Editorial Workflow to manage this internal committee work, and once we are ready to suggest official changes to the main body we put things in the `Ready` state.

If the main body approves those changes, we `Publish`, the changes are merged, and deployed to production. If the main body rejects the changes, we either return to `Draft` to adjust, or delete the work entirely through the "Delete unpublished changes" button. This works flawlessly for Create and Update, as those changes remain on branches even as the trunk (ie, production) remains untouched.

But we have no such analog when we want to Delete a file. Using the current interface, there is no difference between `Unpublish` and `Delete`. Both result in the same thing: the file in question is immediately deleted in the trunk. This is redundant, confusing, and unexpected.

**Describe the solution you'd like**
Extend the Editorial Workflow to include Delete in addition to Create and Update.

**Describe alternatives you've considered**
We currently use the GitHub backend to create delete-only Pull Requests and manage the flow outside of Decap.

**Additional context**
Please note this isn't about preventing accidental deletion, forgetting to push deletions, or privileges on who can make deletions (as in the issues cited above). To me, the value of the Editorial Workflow is that it decouples *making* and *releasing* changes. These are two very different things in most publishing environments, but in Decap when it comes to file Deletion they are inseparable.

I'm proposing that under "Delete", the action be:

1. Creation of a new Branch and corresponding Pull Request, which does nothing more than deletes the file on the branch.
2. Present in the UI that the file is slated for deletion, which could be either through a banner or markup over the existing (ideally disabled) interface, or perhaps simply a message that the file is pending deletion, with perhaps a "Load Diff" to render the proposed deletions similar to how it is done on GitHub.
3. On `Publish`, merge the PR, which deletes the file from the trunk and on deployment removes it from the live site, OR ---->
4. Go back to status quo ante by clicking the `Delete unpublished changes`, which deletes the branch and PR, and brings you back to where you were before.

> Side Note: To me, the `Unpublish` button is misleading, and the entire concept should be removed. Publishing on Decap (as best as I can tell) merges the PR to trunk, and there is no such thing as `git unmerge`. There are many ways to *revert* commits, of course, but that's something different and will always be available on the backend to those who need to overwrite something later. That said, if the thought of saying "Delete the unpublished deletion" is too confusing then that's fine. The main point is to decouple persisting changes from releasing changes. So if anything, the `Unpublish` button should revert the committed changes on the trunk, and re-create a branch/PR with them. This is probably unnecessarily complicated and certainly out of scope for this request, but I offer it FWIW.

Thank you -- your efforts are valued and appreciated.