Destructive changes fail when metadata cannot be found in target org

**Describe the bug**
We are unable to promote Work Items where DevOps Center is attempting to delete metadata which doesn't exist in the target org. Additionally, we have a Work Item where DevOps Center is attempting to delete metadata types which cannot be deleted via the API (Record Type).

Our developers/admins worked on a number of Work Items in development sandboxes. After submitting the Work Items for review & approval, rework was required and some metadata was deleted/renamed. This rework is then committed to the work item, and the deleted metadata is tagged as 'REMOVED' by DevOps Center. The metadata never existed in the target org.

DevOps Center tracks these removed components as destructive changes, and deployments are now failing as the metadata cannot be found in the target org. It doesn't appear to be possible to ignore warnings for destructive changes.

I have been able to add some files to the `.force-ignore` file, but some files such as Custom Fields cannot be ignored as they are combined into Object files by the metadata API. Furthermore, record types are tracked for deletion, but cannot be deleted by the metadata API, so it is not possible to move these Work Items through the pipeline.

**To Reproduce**
Steps to reproduce the behavior:
1. Create a Work Item.
2. Create a metadata file in the target org (e.g. custom field).
3. Commit the change to the Work Item.
4. Create a review (pull request).
5. Delete the field in the source org (or rename the API).
6. Commit the (remove) change to the Work Item.
7. Attempt to promote the Work Item to the next stage in the pipeline.

**Expected behavior**
Either:
- DevOps Center should detect the metadata doesn't (and never existed), in the target branch/org and does not include in a destructive changes file. This should be possible by double checking a `git diff` rather than solely relying on the REMOVE tags from the CLI / DevOps Center.
- Allow `--ignore-warnings` for destructive changes. If the metadata is not found in the target org, this is a non issue for destructive changes.
This could be a feature flag controllable in each DevOps Project settings if necessary.

**Screenshots**