This commit adds special handling for the layer zpos property. Setting it won't
forward it to KMS, instead it will be handled internally.
The plane zpos (either retrieved from KMS if the property is supported, or
guessed from the plane type and ID) is checked during plane allocation to have
the same ordering as the layer zpos. This adds more constraints to the
allocation.
Note that the new constraints are too strict. In case two layers don't overlap,
there's no need for one plane to be on top of the other. See [1].
Also, the new constraints don't account for underlay planes [2].
[1]: https://github.com/emersion/libhwc/issues/3
[2]: https://github.com/emersion/libhwc/issues/7
Closes: https://github.com/emersion/libhwc/issues/4
Given a primary plane with zpos=0 and overlay planes with zpos 1 2, we want
first to allocate the primary plane, then the furthest overlay plane, then the
remaining one: 0 2 1.
References: https://github.com/emersion/libhwc/issues/3
Many drivers don't expose the zpos plane property. We can guess it from the
plane type though: primary, overlay, cursor. Except some drivers expose
underlays too: underlays, primary, overlay, cursor. Underlay planes don't have a
special type, they are just marked as overlays. To detect them, check whether
their plane ID is less than the primary plane ID.
References: https://github.com/emersion/libhwc/issues/3
