Process KeyBinding Command Asyncly for Browser

[amartya4256]

This PR adapts how KeyBindingDispatcher processed Key events in case of Browser. If the trigger of the event is a browser, it processes the command asynchronously to avoid any possible deadlocks.

Contributes to #3104

Problem Explained
KeyBindings are registered globally with the Display. Inside the browser when a key combination is pressed which might open up another browser and use it synchronously, the browser needs to wait for the callback to finish and since it is not possible in case of Edge browser, it goes in a deadlock.

To achieve this, we must process the commands asynchronously. However, we need to tell the browser if the event eats the key event (sets event.doit = false) as the key is handled by SWT and not the browser natively. Hence, we need to proactively check if a command for the key event is going to be executed. If yes, it eats the key otherwise the browser can execute native action on the key event.

[github-actions]

Test Results

 3 015 files  ±0   3 015 suites  ±0   2h 6m 33s ⏱️ -10s
 8 258 tests ±0   8 009 ✅  - 1  248 💤 ±0  0 ❌ ±0  1 🔥 +1 
23 598 runs  ±0  22 804 ✅  - 3  791 💤 ±0  0 ❌ ±0  3 🔥 +3 

For more details on these errors, see this check.

Results for commit d3fe6b9. ± Comparison against base commit 7445acd.

♻️ This comment has been updated with latest results.

[HeikoKlare]

At a first glance, this looks like a reasonable workaround according to the proposal in #3104 (comment).

One concern regarding behavior is the clearance of the keyAssistDialog state. And note that a bunch of related tests is failing now.
My other current comments are rather regarding style.

[HeikoKlare]

Why are two out of three parameters final?
And couldn't you pass a commandExecutor that incorporates the handlerService and trigger/staticContext to avoid so many parameters? I.e., passing a lambda command -> handlerService.executeHandler(command, staticContext) instead of handlerService and trigger separately.

[amartya4256]

we need to dispose the context after the command has been processed. That's why I passed the event and created the context at the time of execution. Can also pass staticContext instead of trigger.

[HeikoKlare]

I see. Then it's probably best to keep the trigger parameter as it's otherwise confusing that you pass over the lifecycle handling for staticContext from the caller to the callee. Instead, the caller would have to dispose it.