Add support subpackage for Git's pathspecs

[mih]

The main (if not only) purpose of this functionality is pathspec mangling/translation for handing them over to analog Git command calls on submodules -- for any Git command that supports pathspecs, but not recursion.

A simple example for such a command is git ls-files --other. It accepts pathspecs, but does not implement --recurse-submodules for listing untracked files.

The goal of this functionality is to be able to take pathspecs that is valid in the context of a top-level repository, and translate it such that the set of paths specs given to the same command running on/in a submodule/subdirectory gives the same results, as if the initial top-level invocation reported them (if it even could).

The included sketch of a testbattery uses ``git ls-files --other` for testing, rather than a formal description -- because the behavior of the implementation is more elaborate than the documentation at https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec suggests.

All testing is (for now) performed within a single repository, and with translation for execution in subdirectories.

The implementation is a rough sketch for exploring the problem, rather than anything polished.

Ping #587

Also see datalad/datalad#6933

TODO:

• ready tests for case-insensitive file systems
• support :(glob) pathspecs via PurePath.match()
• test :(exclude) pathspec handling
• test :(attr:...) pathspec handling
• have another go at figuring out why the icase magic does not work as documented
• add optimization to bypass expensive translations when a pathspec is just a path with no wildcards
• Add constraint to validate pathspecs
• Add pathspec support to iter_submodules(). Alternatively, add pathspec support to iter_gitworktree(). However, the former could be less complex. We could take any reported submodule, and try to port any given pathspec to it, and report only submodule that has any match. In iter_gitworktree() we'd have the problem that git ls-files is totally silent if given a pathspec that points (exclusively) into a submodule.

[mih]

The additions related to next-status now provide a nice test ground for getting this done.

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (3d0c8a4) 92.68% compared to head (5ec4ebf) 26.00%.

Files	Patch %	Lines
datalad_next/gitpathspecs/__init__.py	98.21%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #588       +/-   ##
===========================================
- Coverage   92.68%   26.00%   -66.69%     
===========================================
  Files         160      162        +2     
  Lines       11495    12022      +527     
  Branches     1769     1832       +63     
===========================================
- Hits        10654     3126     -7528     
- Misses        652     8776     +8124     
+ Partials      189      120       -69     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mih]

Leaving a note here re adoption of pathspecs.

I found that one implementation is missing: Recursive discovery of untracked files that honors pathspecs.

A use case would be a recursive save of a pathspec-defined subset.

However, for consistency and simplicity of behavior, even a status report should be able to select or ignore untracked elements by pathspec.

A git status does not do that. A submodule is considered "untracked content" whenever there is any untracked content. It does not pass on pathspecs that may filter out all untracked content, and would make a submodule "clean considering constraints".

For next-status this would have the implication that, when pathspecs are given, we never let Git do a full submodule evaluation, but recursive ourselves.

[mih]

Closing this PR, because #714 has an advanced implementation.