lock_file is a pipe itself. If lock_file is really a pipe & is writeable we
consider that gtic is running now. In the case when no lock_file is found we
fork: the daughter process is parsing tics, the parent one creates lock_file,
intercepts SIGCHLD (to finish, when gtic work is done) & also loops a constant
cycle, which open, read & close a pipe until SIGCHLD is caught. Thus locking
is performed in an easy & crashproof way. This means that not depending on the
numerous kills of our process due to power supply failed, shutdown etc we
perform locking in the right way.

bsy_support - in the case we find a bsy-file when trying to write xlo we
create the gtic_q/xxxxxxxx.xlo file instead of xxxxxxxx.xlo. During the next
tossing we check all gtic_q's in the inbound & outbound, then we try to move
everything we've found in the parent directory if a bsy-file is empty.

Portal of Power (an old dos-ftn mailer\tosser\filefix) somehow creates
tic-files with an Pw field empty. This is a CRUEL standart (FSC-0087)
violation, but we don't really care about that, You know ;) That's why we've
added support for null tic_t->pw. It's performed in this way:
1) we declare pw="*", when no pw is found in the tic-file
2) we consider, that password can be omited when a node password is equal to
"*" in the users file
3) when writing a tic we check if pw="*", this way we omit Pw in tic
The last point is an obvious standart violation, that's why it can be
discussed.

The way we find config files:
1) first we try an optional 3rd commandline argument
2) nothing found, we try to read argv[0]+".config"
3) nothing found even now, we use CONFIG (defined in Makefile), in the case it
was declared.

An area groups support:
1) group should be assigned in the areas file. If a group is not set an area
is avalable for everybody. ext.create_area writes Group $newarea_group in the
areas file. newarea_group is assigned in the config file, by default it's
equal to "" (null) - nothing is written in ext.create_area).
2) Groups list is a 3rd argument, separated by commas, in the users file.
Wildcards usage possible.
3) We check group in the following situations:
- on file arrival (for node tic->from) [badtic]
- on sending file to user (for node tic->to) [skip]
- on listing areas to the user from area manager request [unlisted]
- on linking an area to the user from area manager request [report an error]
4) You can forbid some areas to the users. Put an "!" symbol in the beginning
of list element for enabling it. Algorythm of parsing is easy: first we check
what is prohibited, then we check what is allowed.