Before this commit there were two Critical Regions (CR) that could lead
to race conditions:
* among yad --plug processes, and   
* between yad --key (notebook or paned) and yad --plug processes.

The first CR had been marked as suspected in the existing code with
this comment `/* FIXME: may be race here */` but no fix. This CR
could lead to a race condition between multiple plugs trying to
increment counter `tabs[0].xid++` all at once. Given a collision, the
xid counter would never reach its target value, which is the number of
plugs connected to notebook (or paned). Therefore the notebook
or paned dialog would wait forever and never display their windows.
One could run `ps` and watch several yad processes sleeping in the
process list without visible yad windows.

To fix this problem I redefined the role of `tabs[0].xid` from a
read/write counter to a read-only (from the perspective of plugs)
boolean flag. Only when the flag goes true are the plugs allowed to
write to shared memory -- each plug to its own memory space `tabs[i]`.
This eliminates the CR therefore the problem. With this change only
the yad --key process is allowed to write `tabs[0]`.

The second CR occurred inside function `get_tabs` when the yad --key
process attached shared memory and initialized the `tabs[i]` slots.
In a race condition this initialization could overwrite a plug's slot
_after_ the plug had written the slot. This would make GTK unable to
set up a socket between the plug and the key therefore the key would
hang forever without displaying its window.

To fix this problem I used again `tabs[0].xid` as explained above to
make sure that `tabs[0].xid=1` (TRUE) is set only after the key has
initialized the shared memory block. While the flag is false, plug
can attach shared memory but they aren't allowed to write their slots.
After the flag is set true (and never reset false), each plug can write
only its own slot `tabs[i]`, for which there is no contention.

There was no need to set up a mutex or semaphore to solve the race
conditions.