Formalize patterns for delete/uninstall of configuration dependencies

Problem/Motivation

Currently, in general, we want to enforce dependencies. That is good but some configurations are way to complicated to remove because of a minor failed dependency. especially when there is a fallback for when dependencies are not met. This has come into play on 🐛 When deleting a content type field, users do not realize the related View also is deleted Fixed because when a view depends on a field and that field is removed, the view is removed. 📌 Move the field storage deletion if the last field has been removed to the UI layer Postponed: needs info proposes to bring the field storage dependency management to the UI layer which is a good first step. If the site builder is not moving too fast, and notices they are about to remove a view, they can go update the view before removing the field.

But there is allot of configuration in a view (As with other types of configuration). Remove an entire view because a field removal when there is a fallback field (or other) handler is overkill. Contrib configuration will inevitably become complex as well. When a contrib module defines a fallback for unmet configuration dependencies, that dependency should be considered a soft dependency.

Configuration that depends on content is another example of configuration that might need to be considered a soft dependency.

Proposed resolution

Introduce a "Soft" dependency flag.
Provide warnings but not enforcement for configuration dependencies that are flagged as "Soft" when a dependency is about to be broken.

Remaining tasks

Discuss approach and apply.

User interface changes

Adds additional warning to the UI when a dependency is gong to be broken.

API changes

Adds a "Soft" flag to a dependency.

Data model changes

None.