Initial Commit
Initial milestone - succeeds in hashing all the files.  Now to compare those hashes and find duplicates.
Actually do the comparison now.  This works, but performance is a problem; allowing all I/Os simultaneously fails a bunch of them with error 24 (EMFILE), so I’m having to limit them and I’m not getting the concurrency I expect (or that I had when allowing it to be unlimited and simply keeping the number of input files sufficiently low).  Hmmm.
Switched to CommonCrypto (rather than OpenSSL).
Removed outdated references.
Added a log message upon encountering potential duplicates.
Shrank the per-file high-water mark to 1 MiB, rather than 64 MiB.  In the hope that this will somehow translate into better performance.
Allow 4 (x2) concurrent file hashes simultaneously, rather than 2.  Again, in the largely blind pursuit of better performance.
Added TODO about optimising the full file compare.
Added 2-clause BSD license.
Re-prioritise hashing below starting new file I/Os, on the presumption that it’s better to kick off the I/O as soon as possible, since it’s the limiting factor.
Removed commented-out line that was commented out because it’s wrong.
Ignore xccheckout files.
Ignore subfolders; recurse into them looking for files, but don’t dumbly try to read them as files.
Renamed hashing dispatch queue to “Hash Job Queue”, rather than just “Job Queue”.
Now use mmap when comparing the files, and do so in parallel for up to four at a time.  Yet this doesn’t seem to be any faster than the previous method. :(
Shared the `cadiff` scheme.
Ignore all *.xcbkptlist files.
New compare method using dispatch_io.

This dramatically improves performance for drives which can keep up
(i.e. SSDs).  On mine, the previous method maxed out at ~140 MB/s,
while this method approaches 400 MB/s (about the limit for my SSD).

It doesn't appear to have an impact (good or bad) on spindle disks or
other slower disks (e.g. SD cards).
Removed the last remaining dispatch_sync.