Expand package installer interface with stubbed functions and add capability reporting

[ethangreen-dev]

No description provided.

[anttimaki]

This conflicts in general approach and on the code level with what I've done on #1365. Given that my PR is still waiting for feedback I can't say that it's the way to go though.

On the general approach, I'm not sure I see the value from tracking the capabilities separately, especially since we have no way of knowing if the capabilities-object is actually telling the truth, e.g. by type safety. Granted, I'm probably not aware all of the use cases. And the PackageInstallerV2 approach can also be tricked with "throw NotImplementedError" functions, so IDK if that's much better in practice? Is there some other benefits with this approach I'm not seeing straight away?

On code level:

• InstallerCapability should probably be a type/interface instead of a class?
• PackageInstaller could define "not implemented" implementations for the methods to avoid repetition in each subclass?
• Is it intentional that the methods in GenericProfileInstaller only check for capabilities of the plugin installers, using the legacy code for mod loader installers?

[MythicManiac]

I think the capability reporting is not necessary, or at the very least should not be implemented this way. A better (and typesafe) approach would be to mark the "optional" features in the installer interface as potentially being undefined, which will necessitate checking if the methods exist in downstream code in a typesafe fashion before attempting to call them.

In other words, if the type system is leveraged properly, there's no need to have the capability reporting & stub method implementations at all