Support for case insensitive watches

Summary:
This adds support for case insensitive but case preserving
filesystems, such as HFS+ on MacOS.  At this time, we only have this
support on MacOS.

The level of support implemented by this diff is:

* ASCII case folding; our string routines use `tolower` when we want to
  perform case folding for case insensitive comparisons.  Some of our
  query terms use pcre and fnmatch and request case insensitive
  comparisons.  We rely on whatever their implementation does under the
  covers.   We may need to make a second pass over these and hint to
  pcre that the string is UTF-8 on MacOS.  As a TODO, we should also add
  a configure time option to use ICU case folding.

* Expression terms that match names will default to the case insensitive
  mode of operation when the root is on a case insensitive filesystem.

* The `path` generator does NOT support case insensitive matching.

* We don't support watching across filesystem boundaries, so we dodge
  that bullet.

How it works:

We add a second files hash to watchman_dir.  This second hash is keyed
by the case folded version of the filename, and its purpose is to track
the canonical currently live version of the file, independent of its
case.

The regular files hash will hold the prior versions of the file (eg: if
'a' is renamed to 'A', the files hash should hold a deleted 'a' file and
an existing 'A' file).  In this scenario, lc_files will point to that
same existing 'A' file.

If 'A' is then renamed back to 'a', we have a cheap way to resolve what
it was renamed from (simply look it up in lc_files) and mark that one
deleted, before we revive the old 'a' file.  This is important to us,
because our model is to treat kernel notifications of file changes as
hints that we need to look at the filesystem, and this saves us from
walking all the entries in the dir or the hash to figure things out.

For pathological rapid case changing (eg: 'aaa', 'aaA', 'aAA', 'AAA',
'Aaa' and so on), we assume that the kernel will notify us about each of
these changes, even if we observe the file system visible change before
receiving the corresponding notification.  Since we will always observe
the filesystem after a notification, we should be guaranteed to end up
observing the final representation and with all prior case versions
marked as deleted.

When querying for changes, the existing time index can be used as-is.
When using name based generators, we'll need to revise them to walk the
lc_files hash rather than the files hash.

For tracking case changes in dirs, similar to tracking files, we treat
the old case of the dir as an older incarnation of the dir.  When it
changes case, we model that as a delete of the old case and a
create/change in the tree for the new case.

We don't currently build a case insensitive directory tree.  The
only thing that would benefit from that would be the `path` generator.
We need to review what the path generator should do when it comes
to case insensitivity: should it just walk the current
filesystem-canonical dir tree?  Are there valid use cases for using
the path generator on a historical version of the tree?  Does it
make sense to allow the generator syntax to select the mode of
operation?

Test Plan: `make integration`

Reviewers: sid0

Reviewed By: sid0

Differential Revision: https://phabricator.fb.com/D1256270