fix(lua): make the file scanner work on macOS
fix(lua): make the file scanner work on macOS

As per `man fts_open` on each platform:

    Linux:

           FTS_NOSTAT
                  By default, returned FTSENT structures reference file characteristic  informa‐
                  tion  (the  statp  field) for each file visited.  This option relaxes that re‐
                  quirement as a performance optimization, allowing the fts functions to set the
                  fts_info  field  to  FTS_NSOK  and leave the contents of the statp field unde‐
                  fined.

    macOS:

         FTS_NOSTAT       By default, returned FTSENT structures reference file
                          characteristic information (the statp field) for each file
                          visited.  This option relaxes that requirement as a performance
                          optimization, not calling stat(2) whenever possible.  If
                          stat(2) doesn't need to be called, the fts functions will set
                          the fts_info field to FTS_NSOK; otherwise fts_info will be set
                          to the correct file information value corresponding to the
                          stat(2) information.  In any case, the statp field will always
                          be undefined.  Note that because fts detects directory cycles
                          and dangling symbolic links, stat(2) is always called for
                          directories and is called for symbolic links when FTS_LOGICAL
                          is set.

         FTS_NOSTAT_TYPE  Like FTS_NOSTAT but if the file type is returned by readdir(3),
                          the corresponding file information value is returned in
                          fts_info instead of FTS_NSOK.

So, on Linux, even with `FTS_NOSTAT`, we can distinguish between file
types. On macOS, we just get an `fts_info` of `FTS_NSOK` ("no stat(2)
requested"). macOS defines `FTS_NOSTAT_TYPE` for this use case, and it
works, but I don't think that is available on Linux, so I am guarding
this in an `#ifdef` check.

For comparison, benchmarks:

    Summary of cpu time and (wall time):

               best    avg      sd     +/-   p   (best)    (avg)      (sd)     +/-   p
      buffer 0.04066 0.04066 0.00000 [+0.0%]   (0.04070) (0.04070) (0.00000) [+0.0%]
        file 0.14694 0.14694 0.00000 [+0.0%]   (0.14992) (0.14992) (0.00000) [+0.0%]
        find 0.04599 0.04599 0.00000 [+0.0%]   (0.64438) (0.64438) (0.00000) [+0.0%]
         git 0.04715 0.04715 0.00000 [+0.0%]   (0.92388) (0.92388) (0.00000) [+0.0%]
          rg 0.05675 0.05675 0.00000 [+0.0%]   (1.40587) (1.40587) (0.00000) [+0.0%]
    watchman 0.01419 0.01419 0.00000 [+0.0%]   (1.18937) (1.18937) (0.00000) [+0.0%]
       total 0.35168 0.35168 0.00000 [+0.0%]   (4.35412) (4.35412) (0.00000) [+0.0%]

Differences from Linux (as seen in the previous commit):

- We see the same rough pattern of `file` beating `find` and `git`,
  which in turn beat `rg`. `watchman` is slower than it is on Linux, but
  it still beats `rg`.
- Unsurprisingly, the Linux machine is faster than the 7-year-old Mac.
  The `file` scanner is about 2.5x slower on Mac. The `find` scanner is
  about 3x slower. `git` is over 4x slower. `rg` is a bit over 2x
  slower. `watchman` is waaaay slower; about 100x slower, which explains
  why I had it executing so few times compared to the other scanners;
  there must be some savage networking/socket-related overhead on macOS.
  In any case, like I said, it's still faster than `rg`, so I am going
  to leave it at `times = 100` to make the results easy to compare.

wincent/command-t,wincent/command-t,wincent/command-t