Repository: electron
Issue: [Feature Request]: Non-blocking option for shell.openPath() on macOS
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Electron's [shell.openPath()](https://www.electronjs.org/docs/api/shell#shellopenpathpath) currently has an inconsistent behavior on macOS vs. Linux/Windows. The symptom is most evident with an external app that may take a long time to launch, such as with the [Zui](https://zui.brimdata.io/) Electron app I help support where the problem can be observed with [Wireshark](https://www.wireshark.org/) that can take a long time to open large [pcap](https://en.wikipedia.org/wiki/Pcap) files.

This first video reproduces the ideal behavior on Linux (and the behavior is much the same on Windows). First a user starts to open a large pcap in Wireshark, and we can see it slowly making progress on opening it by observing its filling "thermometer" and increasing counters at the bottom of the window. While Wireshark is in the middle of this long open, the user clicks to open pcap data from within the Zui app, which triggers a call to Electron's `shell.openPath()` that leads to attempting to open the pcap file in Wireshark. As shown here, the behavior on Linux (and Windows) is "non-blocking" such that a separate instance of the Wireshark app opens up while the first instance continues its long open.

https://github.com/electron/electron/assets/5934157/19d69cc1-ae7d-4096-a0be-79c0d53b2367

The second video reproduces the less-desirable behavior on macOS. After repeating the same repro steps, we see that on macOS the open behavior is "blocking" such that focus simply jumps to the Wireshark that was already in the middle of its long open. The user effectively has to wait for the "long open" to complete before their separate pcap can open successfully in that single instance of Wireshark.

https://github.com/electron/electron/assets/5934157/4a2e620f-835d-43e1-995a-369fa8063d73


### Proposed Solution

It seems it would be useful to offer an option to request the "non-blocking" `shell.openPath()` behavior on macOS so the user could see consistent behavior across all of Linux, Windows, and macOS. Based our research, it seems that this can be achieved by having Electron's `shell.openPath()` perform the equivalent of `open -n` on macOS (`-n` described as "Open a new instance of the application(s) even if one is already running" per the `man` page) rather than plain `open`.

### Alternatives Considered

We worked around this problem for a while by creating a fork of [this `open` project](https://github.com/sindresorhus/open) and [modifying it to call `open -n` on macOS](https://github.com/brimdata/zui/blob/2694c7d8b93651b9e8c1997340aaa13e9c03ded4/src/js/lib/open.js#L39-L44). However, as sometimes happens with forked/hacked code, the fork fell into disrepair over time and we've gone back to following the [advice of that project's README](https://github.com/sindresorhus/open?tab=readme-ov-file#open) and using Electron's `shell.openPath()`. However, that means just accepting the blocking behavior on macOS.

### Additional Information

_No response_