Test xdg-popup vs xdg-toplevel

Close for JJ RC1

Series merged. 

Added https://lf-automotivelinux.atlassian.net/browse/SPEC-3344#icft=SPEC-3344 for tracking input focus stuff and this task will be only for the pop-up side of things.

As a minor update, found some minor glitches with the activation/de-activation of the pop-ups and submitted

version 2 for it. 

So I've "kept" that passing of data using notifications events sent when application roles changes. I think that this these could be helpful when having that split roles/fullscreen added.

So the notification can carry out additional data which are set when activating the application, but also when the application state changes, like transitional states between split a fullscreen or something like that. The implementation is not fully, but it is servers the purpose and I plan on adding some further policy hooks to avoid any misuse. 

As it stands now the input will not be affected by the pop-up (obviously the input region of the pop-up will receive focus when clicked touched) but the same will have with the background application. For the moment this will probably be the same, and I'll probably branch out into a new Jira Task.  

You might be aware I've extended the agl-shell-desktop protocol as to allow setting additional roles to windows. With it surfaces can behave like floating pop-ups and can be positioned independently. 

I'm going over the onscreenapp/onstestapp and I've noticed a couple of things that I'd like to clarify a bit better:

• The first one is about input regions, specifically about active input regions. Once the pop-up is activate will the underneath surface still have/receiving input? Should it not? Should this be decided by the policy engine (and implicitly have some kind of policy hook in the API to verify it).

• The second one is about passing data between windows. onstestapp will handle over a JSON to onscreenapp which will display it on the screen. That data passing is done using libhomescreen service, specifically using int LibHomeScreen::showWindow(const char* application_id, json_object* json). For now I've faked this event straight in onscreenapp, but I'm trying to figure what would be the best place to hang off this information. Should we add this out-this-band information using the compositor? If we go with this direction, this kind of surfaces (with the pop-up role) will need to use wayland protocol and bind to a interface that will handle that information off. There's no other way to get the data on the receiving end. Should we instead assume there's a proxy kind of daemon that does this instead? 

 @Scott Murray  what is your take on these?