Support for answered (but not closed) discussions?

Hey!

I've given a try for discussions locking as introduced in #25 but from what I see, the action currently only closes discussions in state of `is:closed is:unlocked`, as stated in the search query in the source code.

Now, this makes total sense for issues and PRs, since those can be either open or closed, and it makes sense to only touch those that are closed. With discussions however, we can have *answered* discussions that are not closed. Of course we could instead answer and close the discussion, but very often even after marking something as answered, it's expected that there can be some related activity before the discussions entered into semi-closed "stale" state which is answered but not closed just yet.

Would it make sense to extend the functionality for discussions and make a query of something like `(is: closed || is:answered) is:unlocked` instead? What I mean is, it'd be welcome addition to close the discussion (in addition to locking it) if it's answered but not closed yet, after given inactivity.

I imagine this as two new options added, in particular:

```
discussion-process-answered: true # whether to process answered discussions in addition to closed
discussion-close-answered: true # whether to close in addition to locking answered discussions, requires discussion-process-answered
```

This way people would have two additional use cases of also locking answered discussions, and optionally also closing them before locking.

Another question is whether we shouldn't have a property that processes *all* not locked discussions instead. Since discussions, unlike issues, do not usually carry "work to be done", they just get stale after some time, so in perfect world I'd like from action to close and lock everything that didn't get update in e.g. `90` days, regardless of whether it's open, answered or closed. So maybe instead of above, it'd make more sense for:

```
discussion-process-statuses: [ 'open', 'closed', 'answered' ] # which statuses to process, defaults to closed
discussion-close-on-lock: true # whether to close the discussion in addition to locking, defaults to false
```

Thanks in advance for considering it!

Start by locating the source-code search query for discussion locking and review how the existing discussion options are configured and tested. Compare the proposed answered/status processing and close-on-lock behaviors, then confirm the intended option design before implementing; done means answered discussions can be processed according to the selected configuration without changing existing defaults.

Written by the indexing model from the issue text.