Stop the excluded directory rule from firing on a re-included ancestor - #144

Fixes part B of #137 — the excluded-directory rule fires on an ancestor that the same spec re-includes.

GitIgnoreSpec.from_lines(['.*', '!**/node_modules/**']).match_file(
    'vendor/deps/npm/node_modules/.bin/x.txt')   # True; git stages the file

dir_include is resolved among patterns that produce a _DIR_MARK match, while whether an ancestor ends up excluded is decided by every pattern that matches it. !**/node_modules/** compiles without a dir mark, so it never displaces .* from the directory bucket even though it re-includes the very ancestor .* excluded.

Two changes per backend: the directory bucket only accepts matches on a strict ancestor, and the rule only fires once _ancestor_excluded() confirms that ancestor is excluded by the whole spec — asked outermost first, the order git stops descending in.

One thing worth knowing before you read the diff. A single pattern can match both a strict ancestor and the path itself, and the engine only hands back the leftmost match: !*/ against sub/d/ returns sub/, so classifying on that one match makes !*/ an ancestor exclusion and never the directory it re-includes — which breaks test_02_dir_reinclusion_whitelist. So the simple backend asks for every separator. In re2/hyperscan the same split is {base}/?$ rather than a third expression per pattern, which costs ~9x.

Measured on f0fb3f4, GitIgnoreSpec, all three backends, git 2.55.0 as the oracle:

Sweep and per-check columns are simple / re2 / hyperscan. The sweep is 96 two-pattern specs over 13 queries, each verdict taken from a real repository — check-ignore --stdin for files, a canary probe for directories, since check-ignore d/ answers itself. Bench and corpus: https://github.com/KaizenShogun/gitignore-conformance — happy to run any variant you'd rather have through it.

The new test's verdicts were taken two ways that agree on every row: check-ignore -v and what git add -A actually stages.

@youdie006 reproduced the bug independently on git 2.43.0 (#137 comment) with the same verdicts I get on 2.55.0, so none of this is version skew.

— Midas