Badge request: Github generic issue search

:clipboard: **Description**

This started as a discussion https://github.com/badges/shields/discussions/5943 but I think we've decided this is a good idea, so I'm moving it to an issue. Here's the plan:

In the github front-end, it is possible to construct fairly nuanced issue/PR queries. For example:
* `is:open is:issue label:core label:bug author:app/sentry-io` - open issues with the labels "core" and "bug" opened by sentry-io bot: https://github.com/badges/shields/issues?q=is%3Aopen+is%3Aissue+label%3Acore+label%3Abug+author%3Aapp%2Fsentry-io
* `is:pr is:closed label:npm-package review:approved author:chris48s` - closed PRs labelled "npm-package" submitted by user "chris48s" with one or more approving reviews: https://github.com/badges/shields/pulls?q=is%3Apr+is%3Aclosed+label%3Anpm-package+review%3Aapproved+author%3Achris48s

We already have a wide variety of github issue badge variants. Rather than gradually implement that syntax one feature request at a time as people want more nuanced queries, lets implement one badge:

Github Issue (with arbitrary query): `/github/issue-search?q=...`

This would allow us to call for example `/github/issue-search?q=repo%3Abadges%2Fshields%20is%3Aopen%20is%3Aissue%20label%3Acore%20label%3Abug%20author%3Aapp%2Fsentry-io`

which would execute the GraphQL query

```gql
query {
search(query: "repo:badges/shields is:open is:issue label:core label:bug author:app/sentry-io", type: ISSUE) {
issueCount
}
}
```

Then we can basically say most of our existing issue badge variants are a special case of that in one way or another (certainly all the ones that just display a total). We could either:

* Make our existing random mashup of github issue/PR variant badges redirects to preset queries on that general badge **or**
* Continue serving those badges directly without issueing a redirect using a single shared `fetch()` function and simplify the internals

Either way, we say "no more presets" and any arbitrary query you can make through the GH frontend can also be a badge and we can clean up this mess:


:link: **Data**

GitHub GraphQL API

:microphone: **Motivation**

* Allow any issue badge for 'number of issues/PRs matching [arbitrary criteria]'
* Tidy up our existing pile of github issue badge variants

Start by locating the existing GitHub issue and pull-request badge variants and the shared GitHub GraphQL integration. Define the `/github/issue-search?q=...` behavior from the issue's example query, then decide how existing count badges should use it. Done means arbitrary GitHub issue or PR searches return the matching issueCount and the existing variants are either redirected or served through shared fetching.

Written by the indexing model from the issue text.