The new file coverage metrics are available in all supported GHES
versions. This PR tags lines of code queries as telemetry queries. Lines
of code information will still be available in the SARIF file, but it
will no longer be displayed in the logging output of the CLI.
The one exception is the metric queries for Java/Kotlin that provides
separate lines of code information for Java and Kotlin. I've kept these
since separate file coverage information for languages like Java and
Kotlin is only available for GHES 3.12 and later.
Some languages have multiple `summary` queries for lines of code,
representing different forms of counting (user written, total, etc).
When Code Scanning sees results from multiple such summary queries in a single run,
it will need to choose one as the primary LoC count to display in the UI.
By ensuring only one query per language has the `lines-of-code` tag,
in future we can teach Code Scanning to look for this particular tag
to identify the primary LoC count.
If a "lines of user code" query is available, use that.
Otherwise use the total "lines of code".
(It is completely fine for multiple queries to be tagged with `summary`.)
This is a proposed method for advertising which queries are measuring
the lines of code in a project in a more robust manner than inspecting
the rule id.
Note that the python "LinesOfUserCode" query should _not_ have this
property, as otherwise the results of the two queries will be summed.
