Concurrency for build job

[newhoggy]

Concurrency will cancel jobs that are obsolete because they have been superseded by a new job, for example if a new commit was pushed to a branch that has a pull request.

In order for this to work properly, the "concurrency group" needs to be defined correctly for the job.

This PR defines the "concurrency group" thus:

a+${{ github.event_name }}
b+${{ github.workflow_ref }}
c+${{ github.job }}
d+${{ matrix.ghc }}
e+${{ matrix.cabal }}
f+${{ matrix.os }}
g+${{ (startsWith(github.ref, 'refs/heads/gh-readonly-queue/') && github.run_id) || github.event.pull_request.number || github.ref }}

The <letter>+ prefix makes it easy to line up with debugging in the build output.

An example concurrency group looks like this:

a+push
b+input-output-hk/cardano-node/.github/workflows/haskell-linux.yml@refs/heads/newhoggy/concurrency-for-build-job
c+linux_ci
d+8.10.7
e+3.8.1.0
f+ubuntu-latest
g+refs/heads/newhoggy/concurrency-for-build-job

These were carefully chosen so that within the same PR request, old jobs are cancelled, but when jobs are created in the job queue, those jobs never get cancelled, because they always get a unique concurrency group.

[angerman]

To be honest, I'm not sure we are being too overly specific here. But that would rather end up in too few cancelled builds, than too many, so I'm good with a conservative approach as taken here.