IMdkit: Track window property offsets correctly

### Problem symptoms

Input Methods relying on IMdkit for XIM support are susceptible to causing
hangs in X clients due to improper requests from the input method to the X server.

The following bug reports by users are related to this issue:

* https://www.libreoffice.org/bugzilla/show_bug.cgi?id=78081
* https://bugzilla.redhat.com/show_bug.cgi?id=452849#c19
* http://tracker.xemacs.org/XEmacs/its/issue565
* https://code.google.com/p/ibus/issues/detail?id=1751
* https://code.google.com/p/ibus/issues/detail?id=1697
* https://code.google.com/p/ibus/issues/detail?id=862
* http://lists.schmorp.de/pipermail/rxvt-unicode/2010q2/001176.html

### Detailed description

The XIM specification requires that XIM tranports over 20 bytes in size
be transferred via window properties. The sender calls XChangeProperty
with PropModeAppend, and instructs the recipient via ClientMessage to
call XGetWindowProperty with delete set to True.

Naive implementations exhibit a race condition because the receiver
could have written more data in the meantime, and XGetWindowProperty
only deletes the property when bytes_after_return is zero. If
bytes_after_return is non-zero, it is necessary to use an offset when
reading from the property again.

To ensure that the property data does not grow indefinitely, Xlib
recycles 21 Atoms in round-robin fashion. Because the XIM specification
does not limit the number of Atom names of the form "_clientXXX" to be
used for data transfer over window properties, an XIM server should be
able to keep of track any number of Atoms, remembering the offset into
each property.

This patch implements correct tracking of property offsets.

Signed-off-by: Klemens Baum <klemensbaum@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>