pw-link: add `--wait` option for connecting two ports

Add a flag asking pw-link to stay alive until it attempts a link creation. The main goal of this feature is to simplify scripting when working with deterministic port specs.

Example usecase: a script that spawns PW clients and wants to create links. Without --wait we are at the mercy of race conditions.

⟩ ./src/tools/pw-link --wait \
      "Midi-Bridge:Midi Through:(capture_0) Midi Through Port-0" \
      "midi-dump:input" &
⟩ pw-mididump &
fish: Job 1, './src/tools/pw-link --wait "Mid…' has ended
⟩ # The process stopped once it managed to create the link.

How we do it:

• In main and on each new port registry event, we ask for a sync. We use awaiting_sync to avoid triggering one sync per new port.
• On sync done, if a connection has been attempted, exit as previously. Else, search for the desired connection using do_link_ports().
• If that search is successful, a proxy is created and next sync will end the event loop. The same data->link_res mechanism as before is used.
• Both the link proxy and listener are stored in struct data and their cleanup is now done at the end of main.

Some notes:

• I wouldn't be surprised if I had forgotten some edge-cases. The most evident one is an already existing link. This gets handled implicitly; we attempt the link proxy creation and this triggers the link_proxy_error.
• Another potential edge-case is if the specification does not match; we'll never exit. I expect people to handle that in their scripts using coreutils timeout or alternatives. There is anyway nothing else to be done on our side.
• I've tested other modes and have not seen any regression.
• Maybe the UI could be different? I thought for example about a --follow that stays alive forever trying to maintain the desired link. If a node/port dissappears it keeps monitoring. That behavior however can be obtained using while true; do pw-link --wait ...; done. The current proposal is therefore in a sense more versatile.