Added t2102 - include_rules should work when the Tupfile is included into another at a different directory depth.

Fix is to change tf->dfd to the current Tupfile's directory before parsing it, since the only part of the parser that uses tf->dfd is the code that find Tuprules.tup files to include.
Added t7048 - monitor caching ghosts bug.

The monitor's entry cache had problems before (t7038 & t7039), which was fixed by having the monitor watch files during the update process. In this case, the nodes being removed by the updater correspond to ghosts rather than actual files, so it can't see a corresponding inotify event to remove its tup entry. Instead a simpler fix is to just invalidate the monitor's entry cache after an update, since we don't know which nodes could have been removed. Since tup doesn't allow directory removals during updates, the dircache is safe and can be kept.
db: Split ghost reclaimable query into two.

The ghost reclaimable check needs to see if there are any other nodes that have the ghost as a directory, as well as check if the ghost points to anybody. I tried to be clever and combine this into one query, but unfortunately with my mediocre SQL that just made it horrendously slow. In particular if there were ghosts being checked with many links, it seems that all links would be pulled in. These could be for parts of the database that were not normally used, so it would result in a lot of I/O access and generate a large pause after tup was seemingly finished updating. For example, in the 'biggittup' project, creating a tmp.c file to include libbb.h, and then removing the include directive would result in the ghost check taking 141s with the old query. With the new queries, the same check takes 0.698s (this is on a cold cache).
db: Print query time with --debug-sql.

With --debug-sql, it was difficult to determine just by monitoring output if a particular query was slow, or if tup is busy doing something else after printing the query line. Now the transaction_check saves off the query string in a temporary buffer, and the buffer and actual query time is displayed when sqlite3_reset() is called (through the msqlite3_reset() wrapper).
parser: Print errors to tf->f instead of stderr where possible.

Sometimes error messages would get dumped outside of the actual parsed Tupfile heading, making it difficult to see what the problem is. This puts most of the error messages inside the temporary output file for the particular Tupfile so they can all be displayed under the node heading. There are a few that still output directly to stderr - those associated with creating/closing the temporary output file itself, and a few memory allocation ones in helper functions that shouldn't ever fail anyway.
Added t7049 - test for monitor --autoparse.

This is similar to --autoupdate, but it just runs the parser instead of the full update.
Merge branch 'fullpath'

Conflicts:
	src/tup/db.c
	tup.1
Unjumble test case numbers.

Had some duplicates because of branching.
man page: Clarify that full_deps and ccache won't work yet.
Add 'tup privileged' command for test cases.

This is a better check to determine if tup is privileged or not, since it doesn't rely on looking at the ls output, but rather it relies on what tup can actually do.
parser: More accurate time reporting.

When tup sees an input from another directory, it stops parsing the current Tupfile and parses the dependent Tupfile. However, the time to parse the second Tupfile would essentially be included in the first one as well because the timespan comprised the whole range of time to parse both. This is potentially confusing, since a Tupfile that is dependent on many other directories could report a large parsing time, even if the actual time is quick. This change subtracts out the time to parse any dependent Tupfiles by adjusting the start time.
Added t4069, t4070 - support for ^c flag for chroot.

This allows a Tupfile to specify that a certain command should be executed in a chroot environment, without having to run everything with full_deps enabled. Mostly this is to support gcc with the --coverage option - without it, gcc will write the @tupjob path into the executable, which doesn't exist when the program runs.

The downside is the somewhat awkward way that it gets specified, but the only other way to get the information to the updater is if there is an extra column in the database, and it still needs to be set somehow in the actual :-rule anyway. Since we already use the ^ TEXT^ area as a weird way of passing metadata to the updater, and there was already space for ^-flags, it seemed like a reasonable fit.
windows: Don't inject into mspdbsrv.exe

The mspdbsrv.exe is spawned by cl.exe if you generate the pdb output, but the process runs as a detached server process in the background after cl.exe returns. If we inject into it, then it will hang on to our deps & output files so we can't remove them.
Expose PKG_CONFIG_PATH for pkg-config to use
monitor: Only autoupdate if we hit the timeout.

We have to save the fact if files were modified from a queue flush (due to overflowing the event queue) or if someone grabbed the lock. Then when we hit a quiet period and timeout, we will do an autoupdate (even if the queue is now empty).
monitor: Need to commit before restarting from overflow.

If we get an overflow event (eg: from rm -rf'ing a large tree), we need to commit the current transaction before restarting the monitor.
monitor: Use dynamic event queue.

This allows the monitor to handle many more events, and won't be limited by an arbitrary sized block of data.
monitor: Always watch file events, even during an update.

We should be able to catch events if a user creates a file while an update (including autoupdate) is taking place. This especially helps with autoupdate while doing a lot of file accesses (such as untarring a large zip) to ensure that tup does not skip any files. The monitor just ignores events on generated files if the timestamps match, so that it doesn't complain that "foo.o" was modified, since it was the updater doing the modification.
Added t7051 - autoupdate should only run once.

After a failed autoupdate, the monitor would see that the updater had removed an output file. This event would cause the monitor to think that files had changed, and therefore run another autoupdate immediately. This logic should only trigger on generated files that have been actually removed (ie: there source command is not in the modify list).
Added t7052 - don't autoupdate twice for new commands.

When a command is run the first time, the monitor sees a different event (IN_MOVED_TO) than if the file already exists. We have to make sure these get ignored for autoupdate purposes.