Improve performance for state update handling

[J-N-K]

Fixes #3620

There are two improvements in this PR:

• The EventHandler now uses a "one-thread-per-subscriber` policy. This prevents single "slow" consumers from blocking others but still preserves event order.
• The PageChangeListener and the SitemapResource have been refactored to use events instead implementing StateChangeListener.

[TheTrueRandom]

Nice improvements, tested on my raspberry pi with > 50 item updates/s which are handled with ease now. Before it was struggling with 30 updates/s.

[lolodomo]

In my TODO list for the weekend to review this PR.

[lolodomo]

This code is probably correct even if I don't understand why it is better to use an event subscriber rather than implementing a StateChangeListener.
As this change updates the core behaviour of any sitemap UI, a very detailed review from @kaikreuzer is really expected. There were subtile code about groups and items state updates in previous code.

@J-N-K : I assume you checked that live update in BasicUI and Android app is still working as expected after your changes ?

[TheTrueRandom]

For me everything on BasicUI and Android app still works as before and I have quite some elements in it.

[lolodomo]

@kaikreuzer and all @openhab/core-maintainers : as it is said that performance are greatly improved (for users considering OH as a real-time system), I believe this PR should be considered. As it impacts a sensible part of sitemap UIs, I would suggest to not wait for the last OH4 minute to merge it but rather include it in coming milestone to have few weeks feedback form users.
I already reviewed the code and it looks OK to me. But I am honest, I do not understand why certain changes lead to improved performance. To be reviewed by someone who knows this part of code if possible.

[kaikreuzer]

Thanks. My assumption is that the multi-threaded eventhandler brings the performance (well it actually shows that the event subscribers are not implemented well, since they are expected to return immediately...).
I do not see why moving to events for the page listeners is relevant here, but I am fine with that change as well. It is the riskier part wrt potential regressions, but I cannot think of a situation where this might be an issue. The only cases that would now differ in behavior are the ones where an item state changes without an event being created; this might only be the case at the system startup, but at that moment we do not care too much about the page update notifications either.

TL;DR: Lgtm, let's merge and have 2 more milestones for testing before GA.

[lolodomo]

I believe the title of the PR could be enhanced to mention that it concerns sitemap UIs.