fix: Use message window for requestSingleInstanceLock

[rzhao271]

Description of Change

Fixes #34235

This PR updates the requestSingleInstanceLock API to use a message window on the second instance to receive data from the first instance. Therefore, when a second instance calls requestSingleInstanceLock:

1. The second instance creates a message window and sends data to the first instance's message window with a data param along with the second instance's message window's name.
2. The first instance reads the message and calls Electron's second-instance event, with which the user can send back an acknowledgement for the second instance to see.
3. The first instance sends back the acknowledgement to the second instance's message window.
4. The second instance reads the message and calls Electron's first-instance-ack event.

This message window flow is much better than the previous named pipe implementation that I wrote because we:

1. Avoid blocking or hanging because there's no handshake, unlike with named pipes.
2. Don't need to use a timer to awkwardly store the ack and then send it, which the previous implementation needed to do due to the way the named pipes were set up.
3. Can send back the acknowledgement with more certainty that we're sending it to the right instance because we pass over the acknowledgement window's name (which contains the second process' process ID and thread ID) to the first instance in step 1 above.
4. Avoid crashing in the case that the first instance is on E17 and the second instance is on E18, or vice versa, because we exit early if the newer parameters are not detected in the messages, and because we don't send back an acknowledgement if we cannot find the acknowledgement window first.

CC @deepak1556

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are both changed and 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: Changed the acknowledgement-passing mechanism of the app.requestSingleInstanceLock() API and second-instance event to fix a few regressions.

[MarshallOfSound]

Just going to drop a spicy change request here.

The previous attempt at this caused not just one but multiple issues. To mitigate the impact of this kind of refactor going forward, can we put this change temporarily behind a fuse such that folks (vscode) can opt in to the new behavior and take the brunt of testing it and apps that are fine with the old behavior that works can stick with it until such time as we are appropriately confident in the new implementation?

[rzhao271]

Sounds good to me
Will look into adding a fuse and/or merging into an internal build for testing first.

[rzhao271]

Closing for now to clear out my unmerged PRs list