Remove IRunScript and replace usage with IScriptHostControl

[SlugFiller]

This is a foundation for #11239 and followup to #11242. Recycled from #11273

Proposed changes

• Remove the deprecated IRunScript
• Add more responsibilities to IScriptHostControl, including various parameters that were passed alongside it.
• Replace various uses of explicit classes (e.g. RevisionGridControl, GitModuleForm) with indirect access via IScriptHostControl, instead.

Merge strategy

I agree that the maintainer squash merge this PR (if the commit message is clear).

---

✒️ I contribute this code under The Developer Certificate of Origin.

[mstv]

The not Control-specific functions of IScriptHostControl should be removed and be called via the anyway mandatory IGitUICommands and a slightly extended IBrowseRepo.

    public sealed class GitUICommands : IGitUICommands
        public IBrowseRepo? BrowseRepo { get; set; }

    public interface IBrowseRepo
    {
        void GoToRef(string refName, bool showNoRevisionMsg, bool toggleSelection = false);
        void SetWorkingDir(string? path, ObjectId? selectedId = null, ObjectId? firstId = null);
        IReadOnlyList<GitRevision> GetSelectedRevisions();
    }

Then there will be no need for IScriptHostControl at all because the pair (IGitUICommands, IWin32Window) suffices - or THostForm : IGitModuleForm, IWin32Window.

initial discussion: #11273 (comment)

Thoughts, @RussKie?

[SlugFiller]

A pair would never suffice, by virtue of being a pair. Because it has to be passed to, and stored inside, the likes of RepoObjectsTree. And there are no intersection types in C#. That's how we went down this rabbit hole in the first place.

The other aspect is adding file selection methods to IScriptHostControl, which is necessary for #11239. So even if it was possible to remove IScriptHostControl, it would only create issues down the line.

And no, replacing it with IGitUICommands is not an option, because of windows like FormCommit that have multiple file lists in them. Having a relatively small, easily extensible interface, allows implementing a different file list for each control within the window. It allows returning the form's common UICommands, while still having customized file lists.

TL;DR IScriptHostControl has to correspond with a control, not a form. Therefore, a form-common (and certainly an app-common) interface is too large to act as a replacement.

[mstv]

You are right that file selection methods should be added to IScriptHostControl.
So I found a rationale why the current IScriptHostControl functions should be moved to IBrowseRepo (#11324): File scripts may benefit from RevisionGrid information, too. Having either files or revisions would be an arbitrary restriction.

Regarding RepoObjectsTree and RevisionGridControl, everything necessary is provided via IGitUICommands. They share the same owner Form.
IScriptHostControl can remain empty in this PR.

[SlugFiller]

IScriptHostControl can already carry both files and revisions if both information is available (e.g. diff view). And can skip the latter when it's unavailable (e.g. commit form). Moving half of that info to IBrowseRepo doesn't make sense, when IBrowseRepo cannot conceivably handle the other half.

You're right that if everything is provided via THostForm, then RepoObjectsTree can simply use FindForm() as GitModuleForm (which, technically, is already a double-hack, using as, as well as using GitModuleForm in place of an intersection type). But the same would not apply to file lists, which would lack the ability to provide per-list overrides this way.

Ultimately, instead of a clean-up refactor, it's a refactor that just makes everything more convoluted and complex. The beauty of IScriptHostControl is that it's relatively tiny, and can easily be extended/proxied with relatively minimal effort. More importantly, it's single-purpose. It's used purely for being passed to RunScript. RunScript does not need to worry about getting other parameters, and IScriptHostControl does not need to worry about having other responsibilities.

[mstv]

Then there will be no need for IScriptHostControl at all because the pair (IGitUICommands, IWin32Window) suffices

This was an unlucky wording. Rather read "the pair" as "the two". And "no need for IScriptHostControl" means for this PR "Removal IRunScript".

IWin32Window is just needed as window owner of selection popups. Every control which wants to execute scripts, can pass its own handle (or its Form's handle).
Every control which operates on a repo, already has an IGitUICommands instance.
There is no need to downcast to GitModuleForm.
THostForm was just a trick in order to pass an owner handle and the IGitUICommands instance in one argument. This can and should be split again.

FileStatusList does not need to have information about e.g. the current checkout - and shall not need to have, which would be necessary if IScriptHostControl would provide information about revisions and files.
Such information about revisions is provided by IBrowseRepo.
What remains? A control wants to provide an interface in order to support additional placeholders ("options") in script arguments.
In the next PR, these will be files - in the future, something different for another control perhaps.
Hence it is nothing other than IAdditionalScriptOptionsParser or IScriptOptionsProvider (and not a "host control").
(Choosing names is not my strength. I am open to proposals.)
IScriptHostControl should not be touched nor used by this PR - after rebase on #11324.
Alternatively, we could supersede this PR with a new one. You or me?

[SlugFiller]

I'm not entirely sure where you're going with this, so definitely you. If it gets accepted, I'll rebase #11239 on it, in the way that makes the most sense given the revised design.