…d for runs that are not from pull requests.

Create a prerequisite job that runs the init step twice, with `tools: null` and `tools: latest`.
Use the outputs of these steps to compare the two CodeQL versions.
Pass the list of distinct tool versions for the analysis job to matrix over.
This lets us test the analysis against both versions, while avoiding duplication
when they are actually the same version.

Create a prerequisite job that runs the init step twice, with `tools: null` and `tools: latest`.
Use the outputs of these steps to compare the two CodeQL versions.
Pass the list of distinct tool versions for the integration tests to use in their matrix strategy.
This avoids redundant test jobs when the default and latest bundles are actually the same version of CodeQL.

`~` is accepted by JSON but not by the Actions context language, so we use `null` to indicate the default version.

…s: latest`

Always test against both the default and latest CodeQL bundle.

This improves test coverage shortly after a CodeQL bundle release, where the latest bundle
may not yet be built into the Actions VM image as the default bundle.

It also saves a manual step during bundle release testing,
since we no longer need to temporarily change the PR checks to `tools: latest`.

There is some redundancy when the latest bundle is the same as the default bundle on the VM image,
but this can be considered a test for the `tools: latest` configuration.

These had some minor overlap checking that the JS is up to date and
there isn't any benefit in having them separate as the jobs are run in
parallel anyway.

Co-authored-by: Chris Gavin <chris@chrisgavin.me>

We can only analyze PRs against those branches we are analyzing on push.

Fix a minor issue in the update-release-branch.py script that performs a
call to `sorted` but doesn't use the output. Since `sorted` does not
operate in place, the call is currently useless. As a result, the function
`get_pr_for_commit` does not currently work as exected. I.e. it is
expected to return the "first" (i.e. lowest PR number), but actually it
returns the first in the list provided by GitHub.

As this is an advanced usage it makes more sense to work to getting this included in the documentation instead.

Also add example from README into workflow to confirm it is accurate.