Because setData can be called inside of a Qt signal handler, a
dataChanged signal handler can then also be called as a result
(since connections made using lambdas are called directly, rather
than being scheduled on the main loop).

In this case it caused item_changed() to be called inside of
selection_changed() in certain cases resulting in 2 CurrentCallViews
to be constructed and one of them was never destroyed.

The fix is to place the handler on the main loop queue via a g_idle
call so that its not called inside of another handler.

Tuleap: #252
Change-Id: I4a091037075af3823fc74cfd80fd3ac5bd7b0926