Implement Mechanism and Gitlab API endpoint to surface what features are available in vs-code

Problem Statement

• graphQL queries assume certain fields exist. vs-code extension versions may vary against the gitlab instances in which they are connected to.
• It is common to have a API version mismatch. We only have the gitlab instance version to reference, but that is not enough distinguish if we are running CE or EE, since certain graphQL fields only exist in EE.

Proposal

• Add a new graphQL endpoint to return a object that determines if a gitlab instance has feature available. The endpoint is tied to a gitlab x.y.z version, and is self aware of whether or not it is CE or EE

{
 features:{
   hasSecurityReports: true,
   hasCodeSuggestions: false,
   ......
 }
}

Example Problem (current behavior)

!920 (merged)

Security Reports is a EE only feature tied to a gitlab graphQL API instance version of %16.1 and greater. But we cannot determine if it is a CE or EE instance to know if the graphQL fields exist.

Instead we silently fail on a graphQL network request failure exemption.

Improved Solution

We avoid the network request entirely, hide/disable or notify the user in the UI because we are feature aware of what the gitlab instance supports for vs-code.