Better assignment of views into HW planes

With the introduction of zpos DRM property and with some HW capable of having overlays disguised as underlay (i.MX8M) we need some better way to handle the compositing mode in the DRM-backend, as to efficiently make use of the HW available. Also, IPU based graphics (i.MX6 and the like) feature this zpos property. The property in some cases (i.MX8) happen to be immutable but in other cases they can be manipulated.

As an immutable zpos means all HW planes are stuck in a particular configuration (and implicitly we have underlay) we need to carefully assess how to expose the underlays placed beneath the scanout. An use case which we'd like to support is basically scanout on top, alpha-blended with 2 underlays. (i.MX8M)

With that in mind, a synthesized version of what would this mean (based on some conversations I had with @daniels and @pq) resulted in the following things that had to be addressed:

1. non-opaque views into overlay planes (even if HW supports we don't allow them)
2. placing overlapping views into overlay planes by making use of zpos DRM property where available (we had no way of knowing if placed in the HW how to z-order them, but with zpos we can)
3. optimal configuration of view assignment if zpos DRM property is non-immutable (what would this imply I have no clue atm)
4. support for underlay which is already tracked at @ #9

For 4. it seems that we have two (2) use-cases to follow up:

• if the #no of views equals that of the HW planes the stacking order matches that of the scenegraph order so basically the scanout can have an AR24 buffer which can expose the underlays. If all views are fullscreen the wallpaper view should be technically ignored by the compositor. For the scanout to be fullscreen and not have a black surface view being injected it should not create the region opaque.
• if the above does not hold true we will hit the rendender because we would need to create a surface hole (or a view with that flag that signifies that) that cuts through the scanout plane. In this case the stacking order of the HW is different that of the scenegraph. As that surface will go through the renderer we will not be able to have only planes mode of compositing but a mixed mode (scanout handles everything on top + cut hole while underlays what it had managed to put in).

Started to address them @ https://gitlab.freedesktop.org/marius.vlad0/weston/commits/alpha-and-zpos-underlay.