fix: Make ElectronBrowser mojo interface frame associated.

[marekharanczyk]

Description of Change

Switch electron implementation of mojo interface to use same message pipe as some if interfaces handling frame in chromium. This will assure proper sequencing of events on browser side wrt electron ipc and frame handling. Otherwise race condition could be seen when objects operating on same models in browser process as standard web api is using, for example:

let child = window.open("https://www.example.com/","my_new_child") // cross site
ipcRenderer.send("do_something_with_child", "my_new_child");

will be racy without the change and ipc event could be handled before window is created (albeit rarely as it is timing dependent).

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed possible race conditions between frame state and electron ipc.

[release-clerk]

Release Notes Persisted

Fixed possible race conditions between frame state and electron ipc.

[trop]

I have automatically backported this PR to "17-x-y", please check out #32815

[miniak]

@marekharanczyk do we need to backport this to 15-x-y and 16-x-y as well?

[marekharanczyk]

I think it needs backporting to 18-x-y as that branch was created after PR, so it is on main and 17 but not 18. Regarding older branches, the problem is definitely there, just hidden for that specific case due to other code, but I am not going to make a call on that, those are stable branches after all and I had not compiled nor tested it extensively there to take that risk.

[miniak]

/trop run backport-to 18-x-y

[trop]

The backport process for this PR has been manually initiated - sending your PR to 18-x-y!

[trop]

I have automatically backported this PR to "18-x-y", please check out #32851