Opening multiple files causes multiple instances of Purr Data app to open

When clicking .pd files in the file manager, each one opens a separate PD instance.

Outside the Flatpak sandbox, PD works as a single-instance app. Starting a second instance exits with the following message:

```
guidir is /opt/purr-data/lib/pd-l2ork/bin
[0114/003211.631856:WARNING:chrome_main_delegate.cc(590)] final extension:
Created new window in existing browser session.
```

The single-instance mechanism in PD is documented here: https://github.com/agraef/purr-data/blob/99ca1d46f52543bcfd664efd423a35aa883b9dfa/pd/nw/pdgui.js#L1706

```
// 1. User is running an instance of Purr Data.
// 2. User runs another instance of Purr Data from the command line, specifying
// files to be opened as command line args. Or, they click on a file which
// in the desktop or file manager which triggers the same behavior.
// 2. A new Pd process starts-- let's call it a "secondary pd engine".
// 3. The secondary pd engine tries to run a new GUI.
// 4. The secondary GUI forwards an "open" message to the currently running GUI.
// 5. The secondary GUI exits (before spawning any windows).
// 6. The original GUI receives the "open" message, finds the port number
// for the secondary Pd engine, and opens a socket to it.
// 7. The original GUI receives a message to set the working directory to
// whatever the secondary Pd engine thinks it should be.
// 8. The original GUI sends a message to the secondary Pd instance, telling
// it to send a list of files to be opened.
// 9. The original GUI receives a message from the secondary Pd instance
// with the list of files.
// 10.For each file to be opened, the original GUI sends a message to the
// _original_ Pd engine to open the file.
// 11.Once these messages have been sent, the original GUI sends a message
// to the secondary Pd engine to quit.
// 12.The original Pd engine opens the files, and the secondary Pd instance
// quits.
```

Question is - at step #4, how does the "open" message get forwarded?

The `sys_startgui()` function in [s_inter.c](https://github.com/agraef/purr-data/blob/master/pd/src/s_inter.c) is responsible for running `nw`.

My guess is that the new `nw` process then communicates with the original one, triggering an [nw.App.open()](http://docs.nwjs.io/en/latest/References/App/#event-openargs) event in the original process.

It's not clear how this communication happens though. The `nw` process does connect to the D-Bus session bus but it doesn't share any objects, so maybe it's not communicating over D-Bus. However, this is probably the only option for implementing communication between different Flatpak sandboxes.

It may be that we need to add some kind of GApplication-based shim in or around the `pd` process so that we behave as Flatpak expects.

Start with pd/src/s_inter.c and the single-instance mechanism documented in pd/nw/pdgui.js. Reproduce opening multiple .pd files through the file manager inside the Flatpak, then trace how the new nw process and existing GUI communicate. Done means one Purr Data instance opens all selected files without launching separate visible instances.

Written by the indexing model from the issue text.