Handling tiled outputs and cloning on Wayland

Tiled outputs are outputs where the display is split into two or more sections that are driven by separate display controllers, and need to be driven as separate connectors with separate crtcs from our side as well. Effectively we have two options for handling these:

1. create one surface per connector, render to every surface separately and present them with once IOCTL for synchronization. Ignoring multi-view extensions, this is very inefficient, but is guaranteed to work
2. create one big surface that spans some or all connectors of the output, and render and present it all in one go. !1174 assumed this would always work with tiled outputs designed for it, but that's not necessarily the case. When it works though it is vastly more efficient than (1)

If one creates a "simulated" tiled output by combining multiple normal outputs, there is also the complexity of possibly having multiple different refresh rates on a single logical output. As that is a niche of a niche of a niche I think we can ignore that use-case though and just render at the highest refresh rate available.

For cloned outputs there are more possibilities:

1. create one surface per connector and render to each surface separately, like for tiled outputs. This is what we're doing now and while incredibly inefficient, it has its use-cases: The outputs could have different color spaces and different refresh rates, which should or potentially need to be driven with those different refresh rates as well
2. create one surface, render to that and then blit to the actual output surfaces, possibly also with color space conversions, and present them all with one IOCTL. This is more efficient than (1)
3. create one surface that can be scanned out on all the connectors, render to that and present it on all outputs with one IOCTL. This is a lot more efficient than (2)
4. create one surface that can be scanned out with one crtc and use that crtc to drive all relevant connectors (obvs also with one IOCTL). This is nearly as efficient as if you'd only be using one monitor

2-4 can be handled as one case from the Compositor side, the drm backend can handle it transparently.

For both of these I think that the backend should provide Compositor with a list of surfaces to render to. This doesn't necessarily need to make the primary plane(s) a special case, cursor & overlay planes will also need positioning limitations (for hw that's weird with cursors, and for overlays on tiled outputs in general) and I think that could be sort of generalized to the bottom planes as well.