Clean up feature detection logic where features are in both GitHub.com and GHES

[andyfeller]

Problem

During a discussion with @williammartin over #9430 and initial prototype, Will called out how most of the features within https://github.com/cli/cli/blob/trunk/internal/featuredetection/feature_detection.go are likely available in GitHub.com and GHES.

This issue is to confirm whether we can reduce the feature detection logic to its essentials, making it easier to reason about and support new work. For features that are available everywhere, then this issue would see that detection logic removed.

Examples

At the time of writing, Issue stateReason field, PullRequest checkRunCount field and PullRequest event field are available in GHES 3.10, which is the oldest supported version.

However, PullRequest isInMergeQueue field is first available in GHES 3.12.

[andyfeller]

Beyond the examples above:

• Repository.pullRequestTemplates field is available in GHES 3.10
• Repository.visibility field is available in GHES 3.10
• Repository.autoMergeAllowed field is available in GHES 3.10

So it seems like we could remove MOST of the existing feature detection outside of isInMergeQueue 🤔

[williammartin]

Part of me wonders why we bother with GQL introspection rather than getting the GHES version from the meta endpoint and just hard coding what is available in each version. Wonder if there is any history around this.