Revisit policy of auto-closing issues

[mhucka]

Currently, the workflow for stale issues (.github/workflows/stale.yml) is set to label something as stale after 30 days of inactivity and auto-close the issue 30 days after that. This is a pretty short duration, so I'd like to propose we review this policy.

Closing inactive issues is a way to reduce the burden on maintainers, of course, but IMHO it's important to balance that against antagonizing contributors. Legit issues don't always see activity within 30 days, and may not be addressable in 60. As it is, we're finding ourselves manually having to reopen some issues, which is actually its own maintenance burden.

Some points to discuss:

• Duration. longer may be better, but infinite duration is also undesirable; we need a happy middle ground.
• Issue types. Maybe some types of issues should have different durations. For example, feature requests could potentially have longer durations.
• Additional procedures. For example, maybe we could add a step of reviewing stale issues & PRs as part of the regular triage process (in biweekly Cirq Cynqs), to decide which ones to deliberately label as triage/wont-fix or similar.

Additional reading:

• The current Cirq triage process documented in the Cirq documentation.
• Open Source Guides's page on Best Practices for Maintainers

[mhucka]

Some examples of what other projects do:

• https://github.com/trilinos/Trilinos/wiki/Handling-Stale-Issues-and-Pull-Requests
• Discussion on discuss.python.org: "Decision needed: should we close stale PRs? and how many lapsed days are PRs considered stale?"

[mhucka]

The docs for the actions/stale action we use mentions an additional flag that might be worth exploring:

exempt-all-milestones: If set to true, issues or pull requests with a milestone will not be marked as stale automatically.

It kind of makes sense that something assigned to a milestone shouldn't be flagged as stale. If we assigned it to a milestone, then presumably we decided it's something we want done, even if it takes longer than the stale issue timeout. What do people think about using this flag?