Revert all the work that happened on the master branch.
Sadly, this is the only way to merge the current development branch back
into master.
It is now abundantly clear that I merged the 1.99 branch far too soon,
and that Clutter 2.0 won't happen any time soon, if at all.
Since having the development happen on a separate branch throws a lot of
people into confusion, let's undo the clutter-1.99 → master merge, and
move back the development of Clutter to the master branch.
In order to do so, we need to do some surgery to the Git repository.
First, we do a massive revert in a single commit of all that happened
since the switch to 1.99 and the API version bump done with the
89a2862b05 commit. The history is too long
to be reverted commit by commit without being extremely messy.
The introspection scanner has become slightly more annoying, in the hope
that people start fixing their annotations. As it turns out, it was the
right move.
The ClutterCanvas content implementation should be used instead, to
avoid stringing along the ClutterTexture API and implementation.
This change requires some minor surgery, as the deprecated section
already contains an header for the previously deprecated methods; plus,
we don't want to deprecate clutter_cairo_set_source_color(). This means
creating a new header to be used for Cairo-related API.
GLib introduced macros that allows defining the lower and upper bounds
of the API to be used by application code.
The lower bound allows to define the minimum version that will trigger
deprecation warnings; the upper bound defines the maximum version that
will trigger compiler warnings for unavailable symbols.
This scheme allows gradually porting application code to a new version
of the API, especially in case of resynchronization after multiple
development cycles.
