Indexing steps are not marked stale when new indexable files are added

[pydsigner]

The variation of processed files for most Steps consists in the files gathered by the containing Rule's Matcher, with any other dependencies remaining consistent from one run to another or defined within the entry-point file itself. For example, JinjaExtendedMarkdownStep will enter for each markdown file matched, then pull in either the default template from the Step configuration or the template defined in the markdown file's frontmatter. This explicit connection ensures that the output HTML will be regenerated any time either the markdown or the Jinja template changes.

In contrast, a Step that generates an index of files, like the CodeIndexStep proposed in #59, enters from the Jinja template itself, and establishes custody connections only to markdown files that exist when a fresh run occurs. If the only change that occurs is an added markdown file, the Step will not have a chance to gather the new file, leading to false up-to-date decisions.

[pydsigner]

Possibilities for correction:

• Add a way for Steps to include wildcard dependencies in their explicit custody information, so they can be marked dirty when new files appear
• Add a method to Step so Steps can perform additional dirty checks
• Workaround with an enumeration Step that matches each indexed file and appends it to a manifest file for the index Step to ingest, rather than embedding a Matcher in the index Step.

[pydsigner]

Perhaps the most sensible approach is to utilize the support for non-Path upstreams to produce a built-in glob upstream checker for the Custodian, which would be marked stale if the glob returned a different set of files.

[pydsigner]

For now, since the issue does not appear in core Steps, we can just address this in #59.