Feat: Rotten Issues

[mviswanathsai]

Description:
This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten. This enables the user to do Kubernetes-like (a very mild like) issue life-cycle management. This is done in Kubernetes using the traige-robot.

As per the changes in this PR, after an issue is created:

1. Stays as is till a value specified by days-before-stale.
2. If no update is done to the issue for this time period, it is then moved to a Stale state.
3. The issue stays labelled as Stale till a time period specified by days-before-rotten.
4. If no update is done to the issue within this time period, it is then moved to a Rotten state.
5. It stays Rotten till a time period specified by days-before-close.
6. If no update is done to the issue within this time frame, then it is closed.

• At each of these stages, the labels can be any arbitrary string the user wants to use for their repository. It is by default, Stale and Rotten.
• On an issue update, the labels added by the action can be removed, or not. That depends on how the user configures the action and it is no different from how the stale action functioned before this PR.
• An issue can be closed without it ever needing to be rotten, in case the user prefers to use the stale action as it originally was. This PR defaults the rotten value to days-before-rotten: -1 i.e., does not rotten any issues and so does not disturb the flow of users who have already setup the action. However, provides the user with the option to use the new state if need be. So the default flow is Stale --> closed.
• The Kubernetes issue lifecycle management follows the following flow:

Note: "This bot" refers to the triage-robot.

    This bot triages issues according to the following rules:
    - After 90d of inactivity, `lifecycle/stale` is applied
    - After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
    - After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed

    This bot triages PRs according to the following rules:
    - After 90d of inactivity, `lifecycle/stale` is applied
    - After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied
    - After 30d of inactivity since `lifecycle/rotten` was applied, the PR is closed

• The tests that has been added/updated to cover the new changes could be improved upon and suggestions are welcome.

Related issue:

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[cooljeanius]

Description: This PR aims to add functionality that lets the user keep an issue in an intermediate state between stale and closed: rotten.

IMO the naming here is kind of counterintuitive; I'd expect stale to come first before rotten...

[mviswanathsai]

Yes, it is stale -> rotten -> closed.

[cooljeanius]

Yes, it is stale -> rotten -> closed.

ah, got it, sorry, I just misunderstood at first... never mind...