Stub binary doesn't support `sys.executable` spawn/multiprocessing

### Describe the bug

The stub binary used to start an app is an effective replacement for the `python` binary; however, it isn't a perfect replacements. `multiprocessing` in spawn mode will try to invoke `sys.executable` to spawn a child; it's also common to use `subprocess` or `os.spawn` to try and start `sys.exectuable` to run other Python code as a subprocess. However, the stub binary doesn't support this kind of execution.

### Steps to reproduce

1. Generate a stub flatpak app
2. Add a call to call `multiprocessing.Process()` and start it with `.start()`

The subprocess will call the parent process entry point, and fail.

### Expected behavior

The function targeted by `Process()` should be invoked with the provided arguments.

### Screenshots

_No response_

### Environment

- Operating System: All Linux
- Python version: All
- Software versions:
- Briefcase: 0.3.12

### Logs

n/a

### Additional context

See https://github.com/beeware/briefcase-macOS-app-template/issues/7 for an analogous report on macOS.

One possible solution would be to add some logic to the stub binary to inspect to see if the parent process is "self"; if so, the execution of the app should be modified to behave as if it were a normal Python binary.

Any solution should also be ported to macOS (beeware/briefcase-macOS-Xcode-template#20) and Windows (beeware/briefcase-windows-VisualStudio-template#8).

Start by locating the stub binary source used by generated Flatpak apps and reproduce the multiprocessing.Process().start() case described in the issue. Trace how sys.executable is invoked for child processes and compare the analogous macOS and Windows template issues. Done means spawn mode and subprocess or os.spawn execution run the requested Python entry point rather than the parent entry point across the referenced templates.

Written by the indexing model from the issue text.