Add wlr/ext foreign toplevel association protocol.

[outfoxxed]

This protocol enables clients to match ext and wlr foreign toplevels without relying on heuristics.
It is intended as a stopgap until ext foreign toplevel management is ready.

[JakeStanger]

My concern with this implementation is that it would still require a client to keep hold of a map of all the pairs.

At the risk of complicating the protocol, perhaps it would be better structured as a couple of get_pair requests, allowing the client to obtain the pairs only as needed. Something like:

<request name="get_pair_for_ext">
  <arg name="toplevel" interface="ext_foreign_toplevel_handle_v1" />
</request>

<request name="get_pair_for_wlr">
  <arg name="toplevel" interface="zwlr_foreign_toplevel_handle_v1" />
</request>

...and everything else to go with it.

[outfoxxed]

My concern with this implementation is that it would still require a client to keep hold of a map of all the pairs.

I don't think thats a particularly large issue, as most of wayland requires clients to track a lot of state.

At the risk of complicating the protocol, perhaps it would be better structured as a couple of get_pair requests, allowing the client to obtain the pairs only as needed.

Since wayland is fully asynchronous you can't do this with objects other than a new_id. Implementing it like this would require a new callback interface that returns the association asynchronously. I'm personally against that.

[JakeStanger]

I don't think thats a particularly large issue

Nah you're right, I think I was overthinking it. Had it in my head otherwise, but any reasonable use-case for this protocol is almost certainly already tracking most if not all clients.