feat: add getUI() to ComponentEvent

[mcollovati]

ComponentEvent exposes the source component but offers no direct way to reach its UI. Listeners that need the UI must dereference an Optional via event.getSource().getUI().ifPresent(...), which is verbose and silently swallows the case where the source is detached.

Add ComponentEvent.getUI() returning UI directly. When the source is itself a UI, it is returned as-is; otherwise the method returns the resolved UI or throws IllegalStateException with a message pointing to getSource().getUI() for code that must handle a detached source. This matches the convention already used by AbstractAttachDetachEvent, UIInitEvent, BeforeEvent and similar event types.

Fixes #18818

[mcollovati]

Adding public UI getUI() to ComponentEvent is binary-compatible: already-compiled code (including third-party add-ons) keeps working.

It is source-incompatible in one narrow case: a subclass of ComponentEvent that declares its own getUI() with a return type that is not assignable to UI. In practice this means a user subclass with public Optional<UI> getUI() will fail to recompile against this release.

[github-actions]

Test Results

 1 395 files  +1   1 395 suites  +1   1h 17m 49s ⏱️ +36s
10 068 tests +3   9 998 ✅ +3  70 💤 ±0  0 ❌ ±0 
10 543 runs  +3  10 464 ✅ +3  79 💤 ±0  0 ❌ ±0 

Results for commit f15fc85. ± Comparison against base commit 8450563.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mstahv]

I wonder if the implementation is now a similar trap as the Component.getUI currently is? So if I start some call sequence that completes in a separate thread, calling getUI may be unsafe again IIRC🤔 Not 100% sure, but this is the reason why I didn't proceed with a PR. My guess originally was that UI instance should be saved when creating an event instance.

[mcollovati]

Saving the UI instance in the event is the best approach, indeed. But this needs a refactoring of all code that creates event instances, since there's not a single point in the framework where you can do it.
But I guess we can safely add a new constructor and then start updating the existing code.