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.