Print backtraces in case an assert fails inside xlib/xcb.

Print backtraces in case an assert fails inside xlib/xcb.

As you know there are some nasty libs / apps doing locking
incorrectly. In order to improve the information given to the user
when he encounters such a situation (people don't run apps in gdb
normally) I created the patch attached.
It's very non-intrusive (and affects only xlib/xcb, Josh told me on
irc that it could be useful for other areas too, personally I don't
think that it's really needed at other places ...).

Some same outputs and the discussion of them:

    lxuser@pdln:/tmp$ ./main
    Got a backtrace:
    #0 /tmp/usr/lib/libxcb-xlib.so.0 [0xb7f9d728]
    #1 /tmp/usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7f9d861]
    #2 ./test.so(function_a+0x11) [0xb7f9f3fd]
    #3 ./test.so(function_b+0x11) [0xb7f9f410]
    #4 ./main [0x80484a7]
    #5 /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e60ebc]
    #6 ./main [0x80483f1]
    main: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
    Aborted

That's kinda the normal situation.

    lxuser@pdln:/tmp$ ./main
    Got a backtrace:
    #0 /tmp/usr/lib/libxcb-xlib.so.0 [0xb7f90728]
    #1 /tmp/usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7f90861]
    #2 /tmp/test.so [0xb7f923cd]
    #3 /tmp/test.so(function_b+0x11) [0xb7f923e0]
    #4 ./main [0x80484ab]
    #5 /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e53ebc]
    #6 ./main [0x80483f1]
    main: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
    Aborted

There are two possible reasons that the name doesn't appear in #2:
a) a hidden symbol or a symbol with statical linkage in a library
b) a symbol in an app not compiled with -rdynamic.
But in both cases you still know _where_ the caller is.

Note that in this example test.so was compiled with
-fomit-frame-pointer; this isn't an issue as _one_ (= the caller)
stack trace is still valid (as long as you don't have the insane idea
to compile xcb with -fo-f-p).

Another issue that may appear is "tail call elimination" (some entries
are mysteriously missing; this is quite ugly, but you still get enough
information so that you can do something useful with the issue e.g. by
disassembling the relevant parts with gdb).

Signed-off-by: Jamey Sharp <jamey@minilop.net>