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.
You might wonder why the number of lines changed, but it's due to `tty`
module receiving its' first update since 2001, so the actual number of
lines DID change :phew:
https://github.com/python/cpython/commits/3.12/Lib/tty.py
Since there is now a difference between Python 2 and Python 3, we need to restrict the lines of code test to only run as Python 3.
Move the `lines-of-code` tag from `py/summary/lines-of-code`.
Code Scanning will eventually look for this tag.
The intent is to treat the number of lines of user code for Python as the summary of
how much code was analysed, ignoring both external libraries and generated code.
This matches the current baseline metric the CodeQL Action computes for Python.
We'll revisit this decision, and the baseline, if necessary.
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.
