Add extra filters to filesystem explorer

[dkaszews]

In addition to parsing .gitignore files, the glug::filesystem::explorer should accept additional filters to limit the output to only matching files. While file filters could be applied externally at the output without any performance hit, possibility to filter directories that are not otherwise ignored (e.g. to skip any unit test code) should be done internally, to cut out that branch as soon as possible.

Implementation can be based on existing .gitignore filters, taking optional list of globs to be treated as top-level unanchored patterns.

[dkaszews]

Adding #17 as a blocker, since fixing that bug requires slight decoupling of filters by considering .gitignore files not strictly inside the iterated tree. Adding extra filters via parameters is a logical extension of that mechanism.

[dkaszews]

For first implementation, if multiple filters are passed, then the file or directory must match at least one of them (patterns are logically ORed). Logical AND and NOT may be implemented in the future once legitimate usecase can be shown.

[dkaszews]

file or directory must match at least one of them

This can be implemented by negating all patterns and prepending catch-all. Examples:

• "" => "" (empty extra filter is a noop)
• "*.hpp" => "*\n!*.hpp" (ignore everything except for *.hpp files

The issue is that this will also ignore all directories unless they also match the directory, so maybe prepending with "*\n*/" (ignore everything except any directory) is a better idea.

This might be more of a UX issue, having to spend more time considering the appropriate API (are patterns a vector or a single string, prenegated?) instead of just how to implement it.

[dkaszews]

It might be a naming issue, the filter being ambiguous between positive "only show matching files" and negative "hide matching files". A solution might be to keep the filter class as-is, since it has well-known gitignore API and unambiguous results via decision enum, but make user-facing switches more explicit like --include and --exclude/ignore (out of scope of this issue).

The negation can be either done at explorer level, only showing files which return decision::ignored, or by inverting the patterns based on algorithm above, or setting the filter to negative mode which inverts the enums. For API, either add a filter::is_empty() to recognise when parameter is skipped, or take std::optional<filter> instead. Suggested name to suggest negation would be something like mandatory filter.

[dkaszews]

Final (hopefully) decision is to separate the existing gitignore-based filters from the new positive ones which should work more like filters present in clang-tidy or gtest:

• defaults to pass-all
• positive filters are spelled as regular globs
• negative filters are prefixed with a minus
• comma separated
• globs prefixed with # are not ignored

Additionally, unlike gitignore, files and directories are treated separately: globs with trailing slash apply to only directories, but globs without one apply only to files instead of both. Anchoring works relative to search target.

This should result in more intuitive and easy to type patterns:

• *.hpp - only search C++ headers
• *.hpp,*.cpp - C++ files
• *.[ch]pp - same but with a set
• *.cpp,-main.* - C++ implementation except main file
• *.hpp,-details/ - headers except those in details directory or subdirectories
• *.hpp,-details/* - same but only ignore those directly in details/ (applies to files instead of directory)

Unfortunately, this requires more work to develop a new glob splitting algorithm and engine, but hopefully some reuse will be possible and the resulting UX will be worth it.