protocol: Require pushing upcoming state to cache on set_sync

Now that we're proposing protocols like wayland-protocols!248 and wayland-protocols!256 synchronous subsurfaces are suddenly exposed to a problem that never existed before.

set_sync's current definition is coherent for a strict "mailbox" content model, but we don't really have that when new protocols create queues of state, or even when we have fences that could result in a content update being presentable between the asynchronous set_sync call and an upcoming vsync.

I'm proposing that any as of yet "unlatched" state the compositor has queued up should be pushed into the subsurface cache on the synchronous transition. This gives the benefits of stopping updates "immediately" on set_sync, and potentially releasing unpresented buffers that the client might want to use for whatever operation it's decided requires synchronous operation.