remove static_lock()/static_unlock() and start to use thread local storage (v2)

While testing https://github.com/lxc/lxc/pull/106, I found that concurrent starts
are hanging time to time. I then reproduced the same problem in master and got following;

 [caglar@oOo:~] sudo gdb -p 16221
 (gdb) bt
 #0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
 #1  0x00007f495526515c in _L_lock_982 () from /lib/x86_64-linux-gnu/libpthread.so.0
 #2  0x00007f4955264fab in __GI___pthread_mutex_lock (mutex=0x7f49556d4600 <static_mutex>) at pthread_mutex_lock.c:64
 #3  0x00007f49554b27a6 in lock_mutex (l=l@entry=0x7f49556d4600 <static_mutex>) at lxclock.c:78
 #4  0x00007f49554b2dac in static_lock () at lxclock.c:330
 #5  0x00007f4955498f71 in lxc_global_config_value (option_name=option_name@entry=0x7f49554c02cf "cgroup.use") at utils.c:273
 #6  0x00007f495549926c in default_cgroup_use () at utils.c:366
 #7  0x00007f49554953bd in lxc_cgroup_load_meta () at cgroup.c:94
 #8  0x00007f495548debc in lxc_spawn (handler=handler@entry=0x7f49200af300) at start.c:783
 #9  0x00007f495548e7a7 in __lxc_start (name=name@entry=0x7f49200b48a0 "lxc-test-concurrent-4", conf=conf@entry=0x7f49200b2030, ops=ops@entry=0x7f49556d3900 <start_ops>, data=data@entry=0x7f495487db90,
    lxcpath=lxcpath@entry=0x7f49200b2010 "/var/lib/lxc") at start.c:951
 #10 0x00007f495548eb9c in lxc_start (name=0x7f49200b48a0 "lxc-test-concurrent-4", argv=argv@entry=0x7f495487dbe0, conf=conf@entry=0x7f49200b2030, lxcpath=0x7f49200b2010 "/var/lib/lxc") at start.c:1048
 #11 0x00007f49554b68f1 in lxcapi_start (c=0x7f49200b1dd0, useinit=<optimized out>, argv=0x7f495487dbe0) at lxccontainer.c:648
 #12 0x0000000000401317 in do_function (arguments=0x1aa80b0) at concurrent.c:94
 #13 0x0000000000401499 in concurrent (arguments=<optimized out>) at concurrent.c:130
 #14 0x00007f4955262f6e in start_thread (arg=0x7f495487e700) at pthread_create.c:311
 #15 0x00007f4954f8d9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

It looks like both parent and child end up with locked mutex thus deadlocks.

I ended up placing values in the thread local storage pool, instead of doing "unlock the lock in the child" dance

Signed-off-by: S.Çağlar Onur <caglar@10ur.org>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>