Placeholder task to discuss/debate more on the improvements and requirements for libhomescreen.

Due to retirement of windowmanager and the need to use agl-shell-desktop in order to activate other applications surfaces (see SPEC-3342) there might be a need to hide the details needed to interact with the compositor (for which I've added SPEC-3327). 

But there are some of the things that need to be taken into consideration:

• we can't use a binding with native wayland objects, and the agl-shell-desktop requires it (the output for instance is needed when activating applications). Some potential work-around would be some mechanism to encode outputs to use real-use naming outputs (like the ones we have the output section, and thus resolving it to some string value which can be passed from the application to libhomescreen to agl-service-homescreen) or maybe the usage of xdg_output extension found in wayland-protocols (qtwayland does bind to it as well, but IDK for what purpose).
• If we can't make that encoding work correctly, an alternative, which I've mostly used in porting application, was to to rely on using the first available output, provided by the QPA (the qtwayland platform abstraction API) that allows clients to access platform specific bits
• Lastly, the WAM integration is stalling at this point and I'm not really sure how it will integrate with all the above. For the moment, the ozone/chromium uses the second approach, in which the output is given automatically (the first one available), with WAM itself never being aware of it. For the HTML5 side of things, the private extension is implemented into ozone/chromium and WAM deals with indirect objects, so we need to think that output itself is an object which can translate to a real wayland one or a easy to pass data type – a string.