Move the `ScopedPreferenceStore` out of the 3.x UI plugins

[vogella]

Perhaps there is a way to move the ScopedPreferenceStore out of the 3.x UI plugins instead?

Or provide an E4 alternative... given the complexity here it seems not good to replicate the same over and over again. Given this is almost always bound to a bundle, one could even think about having this inject-able via a service instead like we have for the scopes already with BundleStateScopeServiceFactory

Originally posted by @laeubi in #4261 (comment)

[vogella]

Comment from @ptziegler:

The ScopedPreferenceStore doesn't use any 3.x-specific functionality, so you could copy the class to an 4.x plugin without any significant changes (or preferably move it to a "neutral" plugin).

Though regardless of whether it's done like this or via a service, migration would be the biggest obstacle. Because in our product, I already see 91 references to the 3.x ScopedPreferenceStore and 1193 references to AbstractUIPlugin.getPreferenceStore(). If there is now a different way of accessing this preference store then that would mean a lot of work.

[ptziegler]

I looked into this a little bit and I think that org.eclipse.jface would be the best location. However this would reintroduce a dependency to org.eclipse.core.runtime, which was removed with 287d23a and I therefore assume to be undesirable.

In principle, a dependency to org.eclipse.equinox.preferences should be sufficient, if there is an easy replacement for Platform.getPreferenceService(). In the worst case, it has to be loaded directly via the OSGi API.

Because this class is used everywhere, I would also keep a dummy implementation in the 3.x plugin. Therefore it probably makes sense to do this via two commits; One where the class is moved and one where the dummy class is created. Otherwise Git won't recognize the class as being moved and the history remains in the dummy class.

[vogella]

@ptziegler send a PR once you are ready, I will have a look

[vogella]

I also think jface is the correct place. I think the dependency to core.runtime can be avoided. The PreferencesService.get call can be inlined.

The consumer change to the moved API should be trival with my new Eclipse MCP server https://github.com/vogellacompany/eclipse-mcp-server and if not I fix it in my MCP server to make it trival. :-)