libweston: fix paint node color invariant

The invariant is clearly documented in code comments, but the code failed to ensure it in all cases. Fix it.

There is one very specific protocol sequence triggered by a development version of the Wine Wayland driver when Chrome (win64 app) is switched from window to fullscreen and then back by pressing F11 key. The switch back triggered

weston: ../libweston/color.c:217: weston_paint_node_ensure_color_transform: Assertion 'it->surf_xform_valid == false' failed

For some reason, that specific protocol sequence causes weston_compositor_build_view_list() to create a transient second view for a sub-surface. In the Chrome traces, I have seen that happen twice per run. The first time it works, the old view gets immediately destroyed. The second time (during un-fullscreening) a new transient view is create and then it fails the invariant check.

The fix is in weston_paint_node_create() which is supposed to ensure the invariant. However, it went through the (new) view's paint node list, which will not contain paint nodes from other views. In hindsight this is an obvious bug, but perhaps all views having exactly one associated surface each somehow confused the author. Since the invariant is about surface+output, go through the surface's paint node list instead. That list contains all the relevant paint nodes by definition.

Fixes: #568 (closed)

cc @afrantzis