Problem/Motivation
While working on #2442757: Move the field storage deletion if the last field has been removed to the UI layer, we noticed that we only have to fix the missing UI output to fix the critical part of this issue, so extracting this into a separate issue, will set that back to normal after this.
Proposed resolution
Expand the field delete form and related base class/trait to support more than one config being deleted, and some changes to make it easier to alter the list as it adds the field that is deleted to the output, which is confusing, so we want to remove that.

Remaining tasks
Not yet sure about the changes to ManageFieldsTest, might extract that method into a separate test to avoid affecting the existing test.
User interface changes
API changes
Data model changes
Comments
Comment #2
berdirHere is the patch from the other issue with some additions like removing ourself and a test.
The test is very hacky right now but works. I think we should extract that into a separate test class, to avoid changing the field name and so on for the other test methods.
Comment #5
berdirForgot to uncomment the crucial line because I was testing if the test is failing as expected. It does ;)
Also moved the test to a separate class now.
This is ready for reviews.
Comment #8
xjmComment #9
jhedstromI was concerned about the screenshot deleting the 'content' view when 'field_tags' are deleted, but I cannot produce that locally with, or without the patch--how does that arise? When I actually delete the tags field, the content view is still there.
The patch itself is looking good, assuming I'm not overlooking or missing something about the views config not being deleted.
Comment #10
berdirSorry, I forgot to mention that I manually added the tags field to the content view to have an example dependency for testing :)
That does of course not happen with with the default content view only with views that actually depend on a field.
Comment #11
jhedstromI've tested this patch again with a view depending on a field, and it works as expected, and the code looks solid.
I am actually now more concerned that adding a field to a view, then deleting that field, deletes the view too--perhaps we need a major follow-up to instead swap in a broken handler into the view?
Comment #12
alexpottCommitted 16b020e and pushed to 8.0.x. Thanks!
Improved the documentation on commit.
Comment #14
yched commented+1 for commit, @Berdir++