client: Remove struct wl_thread_data

client: Remove struct wl_thread_data

The wl_thread_data was introduced to prevent deadlock as explained by
the following commit message.

Since the problem described by the commit message seems to have
disappeared, let's remove it and observe the results.
If we decided to keep this code, we will need to add a reference count
mechanism or something to prevent use after free and memory leaks. I
believe this code will only add complexity and increase the likelihood
of errors.

Wayland specification says clearly that if a thread successfully calls
wl_display_prepare_read_queue(), it must either call
wl_display_read_events() when it's ready or cancel the read intention by
calling wl_display_cancel_read().

So even if a deadlock occur again around this APIs, I believe we should
still handle it as the application's responsibility.

commit 409d548f6d3b43b8a4991619c3effeeed809f789
Author: Boram Park <boram1288.park@samsung.com>
Date:   Fri Apr 8 08:14:42 2016 +0900

    client: use the thread reader_count to fix deadlock.

        Let's see the below scenario.

          1. A thread polls several fds including the wayland's fd.
          2. This thread probably calls wl_display_prepare_read()
             before polling fds.
          3. This thread could be awake by other event source which
             isn't related with wayland fd.
          4. After wake up, this thread could call wl_display_dispatch
             or wl_display_roundtrip for sync operation.

        Then, when this thread got a done event. this thread will fall
        in deadlock because this thread increases +2 reader_count in the
        sam thread. The read_event or cancel_read for the first
        prepare_read is not going to happen because this thread sleeps
        in pthread_cond_wait() line of read_event.

        This problem can be solved by using the reader_count per thread.

        The reader_count of thread will be increased/decreased whenever
        prepare_read, cancel_read and read_event are called.

        However, the original reader_count of display will be increased
        only once per thread. And, when cancel_read and read_event are
        called, it will be decreased to read event from fd and wake up
        other threads. And that, if the thread reader_count is still
        more than 0, it will be increased because it means the thread
        is still polling in somewhere.

    Change-Id: I2e881a6222e5ad380ace7a6d9571d5463cf701d9

Change-Id: Id77a4468fafaafe0fa79fbe186767adb8b09cde1