Possibly add a gitignore parser

[facelessuser]

Parsing a gitignore file is kind of a different kind o animal compared to normal globbing.

1. It is file centric.

2. It seems to operate on the files as it returns them and has behavior such that each rule is applied in order and can undo the last.

   Essentially, this would result in an included file:

   a.txt
   !a.text
   a.txt
   !a.txt
   

   This is different than how we do things currently in normal glob where the all the patterns are taken in context together.

3. When a folder is excluded, it is skipped, and you cannot reinclude it or then process files that weren't evaluated because of it.

4. There is a slightly different handling in regards to MATCHBASE. We apply base matching if there are no /, but they still apply if there is only one at the end, indicating a directory.

5. Lastly, I don't think they allow for [[:ASCII:]] posix style character classes. I'd have to check.

There are probably some other minor things, like there are rules for trailing white space and such, but that would probably be handled by the gitignore parser, once parsed into patterns, they'd be treated like normal patterns.

I imagine if we were to implement this we need to do the following things.

1. Write a parser for a gitignore buffer that returns a list of patterns.
2. Employ something similar to the WcMatch class that streams files. The class would be limited to gitignore features, no configuring of flags.
3. Provide an internal hook that modifies MATCHBASE to distinguish between trailing / vs any / within a path.
4. Possibly provide an internal hook that skips posix character classes if they are not supported (I'm pretty sure they are not).

Another approach would be maybe to have a gitignore filter. This would likely need to break a file path up during evaluation as if it its parts were being streamed from a file tree walker since that is the way gitignore is applied.

It's possible we could just integrate gitignore into the WcMatch class and it could find files as it normally does, but then using a gitignore filter, further remove files relative to the working path.

Anyways, some things to think about.