Asynchronous Browser Access Request dialog

[varjolintu]

Modifies the Access Control Dialog to work asynchronously, similar to the new Password Generator popup. The old/current implementation can break message sync between KeePassXC and the extension if another request for the dialog is retrieved. This can be only fixed when database is locked and reopened, which is not very user friendly.

This PR fixes the following issues:

• When another dialog request is sent, an error is returned to the extension. The dialog must be closed before further intercation with browser is possible.
• Fixes the message sync with browser extension when multiple access requests are retrieved.
• Fixes the message sync if user switches tab to another page when the dialog is visible.
• Fixes accessing the dialog (and message sync) when using multiple browsers and one of them requests the dialog.

Fixes #5765.

Testing strategy

Manually. Needs keepassxreboot/keepassxc-browser#1684 for testing.

Type of change

• ✅ Bug fix (non-breaking change that fixes an issue)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0.44053% with 226 lines in your changes missing coverage. Please review.

Project coverage is 64.44%. Comparing base (612c109) to head (e2899bd).
Report is 386 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/browser/BrowserService.cpp	0.56%	178 Missing ⚠️
src/browser/BrowserAccessControlDialog.cpp	0.00%	27 Missing ⚠️
src/browser/BrowserAction.cpp	0.00%	21 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #8273      +/-   ##
===========================================
- Coverage    64.56%   64.44%   -0.12%     
===========================================
  Files          339      339              
  Lines        43855    43953      +98     
===========================================
+ Hits         28312    28324      +12     
- Misses       15543    15629      +86     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[droidmonkey]

What happens when another selection request is triggered with an existing selection dialog still visible? Do we show another one or reject the current and show a new? Could we cause a situation where you could spam access request dialogs being opened?

[varjolintu]

What happens when another selection request is triggered with an existing selection dialog still visible? Do we show another one or reject the current and show a new? Could we cause a situation where you could spam access request dialogs being opened?

The new request is rejected. It's expected that user responds to the one that's already active.

[droidmonkey]

Just a note: we might want to create a general "Request Struct" that has all this info baked into it and we can pass around to various functions that know what to do with the elements. Would reduce the variable jumble.