It actually messed up with the state being actually set, and having a
transition animation running for it. Now this dichotomy is removed, and
gtk_style_context_state_is_running() only checks whether an animation is
running, leaving state checking to flags & GTK_STATE_FLAG_*.

Both API and file format is documented, there's still missing
a migration doc though.

The case for paned can be guessed out from the height and width,
for handlebox the orientation parameter doesn't make much sense,
and this way it could also be used for resize grips.

Invalidation region coalescing now happens recursively as draw() runs, and the
widget's x/y as now drawing coordinates are 0,0 based.

This function recalculates the style for all widgets on a screen.

These functions allow per-screen style providers. also, the changed signal
will be emitted whenever a style context changes.

This function will regenerate all styling information.

Animation regions are confined through gtk_style_context_[push|pop]_animatable_region,
anything that's painted between these calls will be invalidated if an animation starts
for any of the regions in the stack.

gtk_style_context_notify_state_change() may be called from widgets to indicate a
change for a given GtkStateType, in that case an animation will be started if there
is an animation description for the widget/state.

This support goes from the theming engines, which are able to retrieve
style for different combined states to the CSS provider, where several
state pseudo-classes may be specified, such as:

GtkButton:active:prelight {}

"Child class" is an invented term anyway, and it conceptually defines
identifiable regions in widgets.

These functions will help widgets specify how does one element being painted
relate to other contiguous elements.

gtk_style_lookup_color() now uses this function internally.

This API will be used to have savepoints when adding and removing
style classes information.

Child style classes are like style classes, but with additional positional
information. This would be usually set by the parent container.

Style classes are the replacement of detail strings.

This relates a GtkStyleContext with a widget path, so
all style querying would happen based on it.