bug#68663: Unsaved buffers dialog is unhelpful

[Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>]

In terms of detailed change proposals, my experience tells me that it's 
usually best to test the waters first, see whether there are things that 
I haven't considered initially(there were) and what are the acceptable 
options, both technically and culturally.

> I didn't check, but it sounds like this might point to a real problem.
> Could you please describe in more detail the workflow that you have in
> mind?  What is the exact situation when you see the problem, and why?
In this use case we're talking about a very new user. Lets say this is 
your first time(day) of using Emacs. You don't know about M-x 
save-some-buffers, you're not going to quit with C-x C-c, you don't know 
about C-x C-b, you don't know what the * on the modeline is, you don't 
even know what a modeline is. But before 29 you could still quit Emacs 
and have a decent level of protection from making any unwanted edits. I 
think it's pretty natural for users to often restart any less than 
familiar application when they're thinking that they're doing something 
harmful.

So that's two of the use cases. I've also re-read the previous 
discussions on this topic, to try and present the main use case that is 
benefited by the previous change.

I think the only people who are ONLY doing save all or save none are the 
people who are working on projects with limited scopes in a very 
controlled environment - e.g. the user is usually only making edits 
within a single VC repository(project) and thus every time he quits he 
does not particularly care about the unsaved buffers either way, because 
were the changes in them valuable in any way he'd already have committed 
them. For this use case any extra notification is just an annoyance for 
the user. Maybe to further accommodate such users, there should be an 
easy option to disable any unsaved buffers dialog outright.

Now that we have the use case established, lets also honestly question 
what was so bad about the previous behavior, when we're only looking to 
accommodate this single use case? The same 2 buttons were available 
before, just as they are available now. It was just that there were 
other visually(logically and mentally) distracting other options. Which 
to me does not seem like a problem worthy of sacrificing the other use 
cases to, but obviously YMMV.

Also I think something should be said about this being an instant versus 
vs an incremental operation. Where stuff like a combined diff as 
suggested by Dmitry or the act-able modified buffer list as originally 
suggested by the reporter in #4980 would have some tangible advantages 
in convenience, especially the more straightforward your usage is.

The act-able buffer list seems like a perfect solution here 
convenience-wise, but the way I understand it, it's not feasible 
technically.

As for taking inspiration from other editors, I just had a quick look at 
5 other editors\IDEs I had on hand and basically all the IDEs present 
very much the same act-able buffer list.

The smaller editors generally prefer to avoid asking user anything, 
avoid saving anything and then just restoring the changes on restart. 
Which is another perfectly fine solution that's a no-go for us here. 
Though it may be worth considering as an eventual option, because it 
seems like a perfect fit for the limited scope editing use-case 
described above.