libweston/DRM renderless (planes only) compositing mode

This is an idea suggestion and I have no personal interest in it for now. I just recalled some IRC discussions from months back.

Particularly on closed embedded systems (TVs, set-top-boxes, special video equipment, ...) the whole system from hardware to software may be designed so that all compositing needs should be satisfied by the display hardware, making renderers useless. That is, when things actually work as designed. It will allow to cut costs in hardware e.g. by choosing a very cheap and slow GPU, while still being able to push full framerate 4K whatever video through by using dedicated display hardware features.

To help people develop and push such systems in the wild, libweston/DRM could do a few things:

• Whenever libweston falls back to the renderer at all, make it print the reasons why it did so. This should likely just re-use the framework developed for solving #144.
• Make zwp_linux_dmabuf implementation (the check hook) verify that the created buffer at least has some chances of being scanout-able. Importing as a DRM FB would be the most reliable check, but if that is somehow not acceptable, then the very least the dmabuf format and modifier should be checked against the KMS supported formats and IN_MODIFIERS. If there it seems impossible to scan out the dmabuf directly, reject it, so the client can try something else. This might be crucial since normally client side doesn't really care and relies on luck for scanout-ability.
• The GL-renderer tint mode could be activated to show which parts are render-composited on screen.
• Make Pixman-renderer not reject dmabufs when renderless compositing mode is set. This will allow the system designer to avoid OpenGL completely. All dmabufs should be CPU-mmappable nowadays, so Pixman-renderer could support them instead of just not rendering.