Linting TODO staleness

[MichaelChirico]

Unsure if a new linter or an extension to todo_comment_linter(); #2047 is related.

In codebases encouraging TODO to be linked to a GitHub issue, there's a tendency for these comments to stale out eventually:

# TODO(#1234): Improve this

Later issue #1234 is fixed, but this TODO is still sitting around in the codebase.

We can lint for some common issues:

• TODO(#N) for #N that is not a valid issue
• TODO(#M) for #M that is a valid, but already closed issue

There are two things to consider for design:

• How do we populate the list of valid issues and their statuses? If we just assume GitHub, it's pretty straightforward: use {gh} or just {httr2} (Use {httr2}, not {httr} #2148) to hit the GitHub API. But it would be nice to make a flexible enough design so that users hosting packages/projects on other VCS or even using Jira/Bugzilla/etc. can make use of the functionality.
• When do we so? I think the most natural way is at linter creation time (i.e. in the factory environment) since this will likely be slow.

[AshesITR]

Assuming the number of TODOs with an issue number is small compared to the number of issues there are, I think it will be faster to validate all found issue numbers in bulk once per file linted.

todo_comment_linter() sounds like a good candidate for extension. The interface should be discussed. It will probably need atleast an issue pattern.

Remote validation could be supplied as a function argument (input: character vector of issue IDs, output: logical vector of same length).

The default validator could gradually be extended to pull GitHub URLs from git remotes or DESCRIPTION files.
(Or maybe just from Bugs:?)
It would ideally also handle private repos, i.e. auth.

Issue validation should be Opt-In.

[AshesITR]

Also: Caching these lints should be avoided.