This is initially a copy of the display half of `gbm-kms`, quickly ported to use
only the atomic KMS APIs.

It shall be further developed to usefully use the atomic APIs to fix various TODOs,
and provide support for extra performance features

`DisplayConfigurationOutput.pixel_formats` now contains the list of
accepted pixel formats (or, at least, those pixel formats that are
representable in the `MirPixelFormats` enum; many aren't).

---------

Co-authored-by: tarek-y-ismail <tarek.ismail@canonical.com>
Co-authored-by: Alan Griffiths <alan@octopull.co.uk>

The dance required to actually disable an output (and free its
resources) is surprisingly involved.

We might not actually have a `current_crtc` when `set_power_mode` is called
(notably, when disabling an output we set `mir_power_mode_off`).

Rather than crashing, log an error if we try and turn on an unconfigured
output. Silently ignore trying to turn *off* an unconfigured output,
as it's already off.

The way changing the display mode works is that the
`configure` sets the desired `mode_index`, and then
the *next* `set_crtc` is meant to actually set the mode.

This means that we can wait for correctly-sized content
to present at the new mode, rather than showing a single
black frame before the correct content.

But it also means that `set_crtc` needs to look at
the requested mode, rather than the current mode!

We were trying to pageflip, so let's say that.

Currently we expect to only flip framebuffers that are
the same size, in pixels, as the output mode.

Check in `schedule_page_flip` that this holds. Otherwise,
we must be expecting a modeset and need to go through
the `set_crtc` codepath.

We might, later, update the system to handle using the
display scalers to present framebuffers that aren't the
same size as the output mode.

…SOutput.

This is a different behaviour to `gbm-kms`. On `gbm-kms`, when outputs
have an overlapping view of the logical space they are grouped
together so that they share a single *physical* framebuffer.

When the overlap is great (such as a complete clone), this
should result in lower GPU memory usage (as we need only a single
set of framebuffers for all clones) at the cost of tying
the refresh rates of each clone together. (And some bugs, like
#3641).

When the overlap is *not* great, this potential memory saving
goes away (and may indeed result in *higher* GPU memory usage -
if outputs have different sizes, we may now need to have a
bunch of unused pixels, as the FB can only be rectangular).

For Atomic KMS, instead, we give each output its own physical
framebuffer, regardless of whether it overlaps.

…pdate_from_hardware_state()`

*Almost* all of this is only accessed on a single thread, the compositor's
submission thread.

*Almost*.

Unfortunately, `configure` is generally called from the ServerAction loop,
which is a different thread to the composition thread. `ensure_crtc` can
also (transitively) be called from `configuration`, which also happens
off-composition-thread.

Wrap this ball of wax up in a `mir::Synchronised<>`, to ensure we're
not racy.

(This also affects `gbm-kms`, but to a much lesser extent)