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