Drift alerts as issues

[ZIJ]

Currently, Digger sends drift alerts via Slack only. This however makes them just FYI - there is no way to trace what happens to each alert, other than threads or emoji reactions.

User suggestion: create GitHub issues for drift alerts instead. This way it can be tracked, or explicitly closed.

Considerations:

Q1: how many alerts?

• Option 1: a separate issue for each project
• Option 2: an aggregate issue for the entire repo

Q2: what to do with outdated issues?

Say drift detection ran, and an issue was created. No one did anything about it. The next day, more drift happened. Now there is another issue with more up-to-date drift info.

• Option 1: automatically close outdated issues (all? or only the immediately preceding one? or only ones that don't have user activity?)
• Option 2: keep them open (perhaps add comments linking to the newest version)

Proposed approach (subject to change) - Option 1 on Q1, Option 1 on Q2

• On every run, an issue is created for each project that has drift detected
• If there are older issues with drift for the same project: if it has discussions or open PRs, a comment is added and it is marked as duplicate; if it doesn't have any activity, it is closed

[maciej-ciach]

I like the idea of separate issues for each project.

Each issue contains SINGLE comment that is updated with the most recent drift to reflect the latest drift state.

Issue deletion should be handled manually, not by the digger itself.

[ZIJ]

Issue creation added in #1239
Keeping this open for now because we'd also need to add updating and closing logic