Fix various startup issues

[Nadahar]

This started out with a narrow focus on the Graal problems (and there's an upcoming companion PR for add-ons), but grew as I found more problems.

It's really 3 parts:

• A shared Graal language lock that is intended to make sure that every bundle sees the same languages. There are many design decisions to be discussed here, the whole organisation of where to put this shared code, features, bundles etc. - and whether the lock is the right solution.
• A modification of how the automation/scriptEngineFactories ready marker for start level 40 works. Up until now, the script engines have been considered ready as soon as the bundle has started. But, that's not actually "true", some of them need some time to initialize asynchronously. I've created a mechanism to make it actually wait until the engine says it's "ready". This defaults to true so that engines that don't implement this will still work the "old way" - that is, satisfy the requirement as soon as the bundle has been activated.
• A refactoring of how WatchServiceImpl registers with OSGi. The current implementation mixes declarative style/annotations and programmatic registration, which causes problems. These problems have probably been around since Refactor WatchService #3004. DS is single-threaded, so it's not thread-safe. Making other threads also do registrations causes problems with visibility between components, which manifests, for example, with services that are claimed to be ACTIVE return null instances. I've managed to find a way to avoid doing manual service registration by manipulating ConfigurationAdmin instead. It seems to relieve the problem.

I'm leaving it as a draft, since I'm sure there are many things that will need to be changed/rearranged etc.

What can be said is that with this, and the corresponding changes I've done to addons, JS scripting and Python scripting seem to be able to coexist happily, and startup behavior seems much more consistent/predictable without these "random failures" that currently exist where the solution is to ask the user to restart OH. I haven't built and tested this under Karaf, but I strongly suspect that this will make it possible to install/uninstall Graal add-ons dynamically, without having to restart OH, like all other add-ons.

[Nadahar]

The build fails because of a test failure:

[ERROR]   ExpireManagerTest.testIgnoreCommandDoesNotExtendExpiryOnStateUpdate:235 
Wanted but not invoked:
eventPublisherMock.post(<any>);
-> at org.openhab.core.internal.items.ExpireManagerTest.testIgnoreCommandDoesNotExtendExpiryOnStateUpdate(ExpireManagerTest.java:235)
Actually, there were zero interactions with this mock.

I had that locally too, but wrote it off as a flaky test because as far as I know, I've changed nothing that relates to ExpireManager. But, since it fails here too, I guess I have somehow impacted that, although I have no idea how.

edit: The test passed on Java 21 but failed on Java 25, so I still think it's just flaky. But, perhaps some of these changes have somehow made it more likely to fail?

edit2: I've looked at the failing test, and there's no way it can be related to this PR. The whole test class depends on specific timings with lots of sleep statements, so it's fundamentally flaky. I can't see any recent changes to it though, but I guess there can be any number of things that have impacted how this runs. This particular flakiness seems to stem from #2954. I don't see any easy way to remove the flakiness, because expiry depends on timeouts, so it is "timing-based by design". It's still very vulnerable to failure on slow builders. The particular failure that failed here could be fixed by adding a timeout() to the verify() instead of the above sleep, but the overall design is still based on timing, and I don't know if it's this very test that fails each time, or if it's one of the many other opportunities for timing-based failure in that test class.