Don't measure time for creating wiboxes

Apparently some of the last commits speeds up create_wibox() a lot. This
highlights that this is a bad test: After creating thousands of wiboxes, awesome
needed 15 seconds to draw all of them and in the end some dbus timeout aborted
the test run.

However, it's irrelevant how quickly we can create wibox. The interesting number
is how quickly we can display a new wibox. Thus, this commits changes the code
so that it also measures the time that is needed to update the wibox. This way,
we don't accumulate a huge number of pending repaints and everything's fine.

Some results (but there is nothing to compare this with):
   create&draw wibox: 0.0373947  sec/iter ( 28 iters, 1.59 sec for benchmark)
    update textclock: 0.00198174 sec/iter (515 iters, 1.937 sec for benchmark)
  relayout textclock: 0.000614439 sec/iter (1710 iters, 1.051 sec for benchmark)
    redraw textclock: 0.00116882 sec/iter (865 iters, 2.962 sec for benchmark)
          tag switch: 0.000705579 sec/iter (1498 iters, 3.703 sec for benchmark)

Signed-off-by: Uli Schlachter <psychon@znc.in>

tests/test-benchmark.lua

@@ -39,6 +39,11 @@ local function do_pending_repaint()
     awesome.emit_signal("refresh")
 end
 
+local function create_and_draw_wibox()
+    create_wibox()
+    do_pending_repaint()
+end
+
 local wb, textclock = create_wibox()
 
 local function relayout_textclock()
@@ -61,7 +66,7 @@ local function e2e_tag_switch()
     do_pending_repaint()
 end
 
-benchmark(create_wibox, "create wibox")
+benchmark(create_and_draw_wibox, "create&draw wibox")
 benchmark(update_textclock, "update textclock")
 benchmark(relayout_textclock, "relayout textclock")
 benchmark(redraw_textclock, "redraw textclock")