Added t4150 - make sure we can hit the max fd limit still close/open.

This mimics what gold does - it will open a ton of files, hit the fd limit, and then try to close one before opening another. In the fuse fs, the flush() call was trying to dup another file descriptor, which was failing since we didn't have any left. This close(dup()) doesn't seem to do anything for us, so pull it out.
Added t4151 - another max files test.

In this case, we try to open and read from each file. For some reason, the last few file descriptors are returned successfully even though they can't be read from. We need to return -errno if the fd isn't opened correctly, rather than always return 0.
Added t4152 - max files test with mmap.

In this case we open the files and then mmap() them. When we close the last file, we don't munmap() it, so FUSE still thinks it is open. In this case we still want to be able to open & read/write files. This is done by keeping track of how many files are open by the sub-process, and if it goes over a limit, we use the fusexmp model of doing an open()/read()/close() on a read call, rather than keeping the fd open in FUSE. This hurts performance in cases where many file descriptors are open, but at least keeps the system running (in particular for the gold linker).
Remove individual st->lock and use statuslock.

For some reason, when locking the finfo struct in server.c, helgrind will complain that the pthread_mutex_lock() on finfo->lock conflicts with pthread_mutex_unlock() in child_wait_notifer():

==19453== Possible data race during write of size 4 at 0xAF65A60 by thread #12
==19453== Locks held: none
==19453==    at 0x4C2FC73: pthread_mutex_lock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==19453==    by 0x41FEAC: finfo_lock (file.c:79)
...
==19453== This conflicts with a previous read of size 4 by thread #2
==19453== Locks held: 1, at address 0x75EB80
==19453==    at 0x4E4107C: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:52)
==19453==    by 0x4C30373: pthread_mutex_unlock (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)

This is quite nonsensical, since they are two different locks. Using just the statuslock seems to avoid the issue.
Update SQLite 3.7.17 -> 3.8.0
Add vim-common as a project dependency

build system uses xxd tool from vim-common package
Print which commands are skipped in a partial update with --verbose.
Added t3080 - make sure we can add extra outputs when using a !-macro.
Remove debugging.
Add -DLUA_USE_MKSTEMP to avoid tmpnam warning.
Also add -DLUA_USE_MKSTEMP during bootstrap.
Added t4153, t4154 - No-op chmods on temporary directories, and statfs support.
Added t8083 - include path checks for lua code.
Updated t5034 - make sure we can write to a hidden file multiple times.
Updated t4062 - make sure '/' doesn't get parsed.
Added t5081 - touch a hidden file multiple times.
Add Tupfile.ini support. Obselete `tup init`

This commit seeks to obviate the explicit calling of `tup init`. When
tup is run, it will now search for both a `.tup` directory or
`Tupfile.ini` configuration files on the path down to the root
directory. If no `.tup` directory is found, tup will consider the
directory closest to the root that had a `Tupfile.ini` file as the root
of the project and automatically call `tup init` in that directory.

Any `Tupfile.ini` encountered along the way to the root is parsed as a
configuration file (such as the `.tup/options` or `/etc/tup/options`
files). The ini files are added to the configuration search in the order
they are found, that is a `Tupfile.ini` in the directory `tup` is run
from has the highest precedence. Note: This has the interesting property
that things in `Tupfile.ini` files are explicitly not project-global
unless they are in the root directory of the project.

The contents of `Tupfile.ini` files are not tracked in tup's database,
rather they are re-parsed on every invocation of tup. This is a design
choice, as the configuration elements in the ini files are designed to
affect the behavoir of tup as a program, not tup as a build system. In a
correct system, the options exposed by the ini files should not be able
to affect net result of a build.

To appease the idiom of `tup init && tup upd`, repeated calls to init
will print a warning indicating that tup has already been init'd, but
will still return success.
Remove `tup upd` command in favor of simply `tup`

This commit deprecates the command `tup upd` in favor of the simpler,
shorter command `tup`. Now that `tup init` is not required, there was only
one "basic" tup command remaining: upd. This allows for much easier
migration to tup for refugees from other "build systems", using tup is now
as simple as just typing 'tup'.

The command `tup upd` is preserved for legacy / backwards-compatability
reasons. It is silently accepted.
Update `test/tup.sh` to accommodate init, upd

None of the tests failed (on OS X at least), but these changes eliminate
the large numbers of warnings that printed.

Test t0001 is updated to create a Tupfile.ini in the custom init
directory that it creates.

Test t7052 is updated to expect the monitor to run twice, as it detects
the call to `touch Tupfile.ini` from the test framework.
Add post_init.varaints hook for default variants

This commit adds support for default variants. It adds an option entry
called post_init.variants that takes a list of variants to be run. The
hook is called any time that `init_command()` is run, whether implicitly
or by an explicit tup init.

The init() process is re-arranged slightly so that tup is fully init'd
when the post_init hooks run. For similar reasons, find_tup_dir is
converted to a singleton.