Schedule frames for each stage views separately

This branch, while being quite large, has one major aim: split up the frame clock so that on the native backend each CRTC is driven by its own frame clock. In effect this means that e.g. a 144 Hz monitor and a 60 Hz monitor being active in the same session will not have to wait for each other to render. A window on the 144 Hz monitor will paint at 144 Hz, and mutter will composite to the monitor at 144 Hz, while a window on the 60 Hz monitor will paint at 60 Hz and mutter will composite to the monitor at 60 Hz.

This is achieved by a number of changes:

• Remove ClutterMasterClock(Default)

This was the main frame clock that drove clutter painting. Over the last cycles, there has been some attempts to make it handle multiple monitors slightly better, but in general, the fundamental design of it has been incompatible with individual frame scheduling.

• Introduce ClutterFrameClock

This is the new frame clock, that aims to drive a single "output". Right now, it has a fixed refresh rate, and a single "frame listener" and "presenter" notifying about frames being presented.

• Each ClutterStageView owns its own ClutterFrameClock

As in the native backend there exists one stage view for each CRTC, by having the stage view own its own frame clock, we effectively get a frame clock per CRTC. The stage view is responsible for interacting with it, e.g. notifying about frames being presented, and handling the frame clock dispatching.

• All frame scheduling is moved from ClutterMasterClockDefault, ClutterStage, ClutterStageCogl, MetaRendererNative, MetaStageNative, MetaStageX11 to ClutterFrameClock and ClutterStageView.

The logic dealing with scheduling frames (including flip counting, schedule time calculation, etc) was spread out to many places; the aim has been to concentrate all of it to two: the frame clock itself and frame clock driver (stage view).

• ClutterTimeline (thus ClutterTransition) are always associated with an actor

Timelines and transitions saw frames whenever the master clock ticked. With the master clock gone, they need to find an appropriate frame clock to drive them. In most (and after this merge request all) cases a timeline was used to directly drive an animation related to an actor. This indirect relationship is now made explicit, and the timeline uses the actor to find what stage view it is being displayed on, and with that information, picks an appropriate frame clock to attach to.

If an actor moves to different stage view, the timeline will be notified about this and might migrate to a different frame clock.

• X11 session behavior practically unchanged

In the X11 session, we composite the whole X11 screen at once, without any separation between monitors. This remains unchanged, with the difference being where scheduling takes place (as mentioned in an earlier point)

• Various minor API changes

Signals related to painting has seen ClutterStageView added as a signal parameter to let listeners know what is actually painted.

This is currently marked as WIP as it includes another merge request that this depends on: !1196 (merged) and !1289 (merged).

Corresponding gnome-shell MR: gnome-shell!1299 (merged)