Unify our various places where resources are being saved

[bpasero]

To enable full support of virtual document saving (starting with #10547):

• make our dirty indicators outside the editor fit for this
• support auto save (or not?)
• support hot exit
• support save participants
• support to set the encoding for saving
• support undo properly (undo enough to get back to saved state)
• support to search through resources (today we only search file & untitled)
• revisit our hardcoded assumptions in places like actions that only think file & untitled resources are editable
• debt: make the confirmation dialog reusable
• debt: reuse more code between file saving and resource saving

[bpasero]

/cc @jrieken @egamma this is the issue I captured on enabling resources to be writeable. It seems that we are picking this up again in September, so should I reserve time for it?

[jrieken]

Well, at least the assumption for file and untitled need to be revisited. I have come a long way with my changes in #34229 so most might be just debt

debt: reuse more code between file saving and resource saving

What puzzles me is that the text model contains a lot of save-dupe code while I would have assumed that such things belong into the service

[bpasero]

What puzzles me is that the text model contains a lot of save-dupe code while I would have assumed that such things belong into the service

Yeah, a lot of that code is from time where we had no services ;)

[bpasero]

@jrieken so it seems your changes basically enable to use ITextFileEditorModel with resources that are not file:// scheme. Maybe we should just rename our ResourceInput/Model to ReadonlyResourceInput/Model and the file related classes to EditableResourceInput/Model at some point. If so, it seems that there is remaining work left to:

• revisit our various toResource calls and assumptions
• make sure we are not using URI.file unless the client is really about dealing only with files