Adding @mjbvz for custom editors, adding @bpasero as feature area owner

Submitted as a draft PR seeking comment and guidance from @jrieken about taking this through the API proposal precedure.

The checks are in place and things are defined proposed.d.ts - so all good from that side. All API proposals are discussed during a weekly call and I can represent this issue. So far, the FS provider API has been posix-like and this isn't strictly like it anymore, tho personally I don't mind it.

* isn't `mainThreadFileSystem#$stat` missing to set the `readonly` flag?

Added in latest push.

* this should get a test to verify the text editor model reports readonly for readonly file stat

I'd appreciate some guidance on doing this.

I have updated my branch of fsprovider-sample so the readonly state of a file can be toggled while open. If I close the file tab and reopen it the readonly state of the editor changes, but I think this needs to happen dynamically. @bpasero you recently did something similar in #110854 to handle a FSP's readonly capability changing on the fly.

I am back at my desk after the holidays, so I've removed draft status from this PR.

@gjsjohnmurray sorry for the time this took. I tried to bring your branch up to date with main but I do not have permissions it seems to push. Anyway, maybe you can force your branch to be on this commit and then we can proceed here: cf122a2

Remaining tasks:

• test coverage (aka ensure the readonly change event fires when a underlying provider changes readonly state for a file) [1]
• make sure the editor control updates properly based on readonly changes, similar to how we currently do it when the provider capabilities change ([2]). A provider that after some time decides to change the readonly state for a file should reflect in the editor turning readonly or not

[1]
As for best ways how to test this, I would suggest to look at the src/vs/workbench/services/workingCopy/test/browser/fileWorkingCopy.test.ts. file working copies will eventually be the default for text file model too, so we do not have to add tests for both. I would think that the coverage should be:

• the onDidChangeReadonly event firing properly
• the isReadonly respecting the last resolved file stat or fallback to the system provider readonlyness

[2]

I tried to bring your branch up to date with main but I do not have permissions it seems to push. Anyway, maybe you can force your branch to be on this commit and then we can proceed here: cf122a2

@bpasero I'm not familiar with this procedure. I have now set the PR's checkbox Allow edits and access to secrets by maintainers, so maybe you can do it yourself now. Or else please tell me the git command to issue or the option to pick from the SCM ... menu in VS Code.

@gjsjohnmurray done

@gjsjohnmurray are you planning to work on this further? Otherwise I can look into the finishing touches.

From a API discussion we had today, we picked one of the proposals from #73122 (comment). Basically it would be this:

export enum FileStatPermissions {
	/**
	 * The file is readonly.
	 */
	Readonly = 1
}

/**
 * The `FileStat`-type represents metadata about a file
 */
export interface FileStat {

	/**
	 * The permissions of the file, e.g. whether the file is readonly.
	 *
	 * *Note:* This value might be a bitmask, e.g. `FileStatPermissions.Readonly | FileStatPermissions.Other`.
	 */
	permissions?: FileStatPermissions;
}

@bpasero I'll happily leave it in your safe hands. Thanks!

Thanks 🥂