Revert "actor: don't immediately queue redraw when queuing relayout"

This reverts commit ca44c6a7d8abe9f2c548bee817559ea8adaa7a80.

In reality there are probably lots of actors that depend on the exact
semantics as they are documented so this change isn't really acceptable.
For example when the font changes in ClutterText we only queue a
relayout, and since it's possible that the font will have the same size
and the actor won't get a new allocation it wouldn't otherwise queue a
redraw.

Since queue_redraw requests now get deferred until just before a paint
run it is actually no longer a problem to queue the redraw here.

clutter/clutter-actor.c

@@ -5250,27 +5250,7 @@ clutter_actor_queue_relayout (ClutterActor *self)
 {
   _clutter_actor_queue_only_relayout (self);
 
-  /* XXX: We have bent the originally documented semantics a bit so
-   * now where we say "Queueing a new layout automatically queues
-   * a redraw as well" it might be clearer to say "Queuing a new
-   * layout implicitly queues a redraw as well if anything in the
-   * layout changes".
-   *
-   * If we don't comment this out then we fail to take advantage
-   * of clipped redraws in a lot of cases because queuing a redraw
-   * with priv->needs_allocation == TRUE will automatically be
-   * promoted to a full stage redraw since it's not possible to
-   * determine a valid paint-volume.
-   *
-   * It doesn't just work to do the queue redraw first. I didn't debug
-   * why in detail but at the very least it would end up registering a
-   * redundant clipped redraw for the current location, doing quite a
-   * lot of redundant transforms, and then later when allocated
-   * another queue redraw will happen with the correct paint-volume.
-   */
-#if 0
   clutter_actor_queue_redraw (self);
-#endif
 }
 
 /**