Add `zizmor.yml` workflow

[hknutsen]

Add a new workflow zizmor.yml that sets up and runs zizmor, outputs scan results to a SARIF (Static Analysis Results Interchange Format) file, then uploads that file to GitHub Advanced Security (GHAS).

[sefornes]

@equinor/cyclops-subsurface Reopened the issue to facilitate a discussion how we should structure the workflow.

[hknutsen]

@equinor/ops-actions-maintainers We talked about appending -ghas or -codeql to the workflow to clarify that it integrates with GHAS / CodeQL.

Do we want to do that, or should we instead add a new best practice that Super-linter should be preferred for running linters, however that linter-specific workflows can be created when it supports integration with GHAS / CodeQL?

[sefornes]

I think suffixing is a very good idea.

When it comes to super-linter, I'm getting increasingly sceptical to it. My concerns are primarily:

1. They suddenly include new linters, of more or less usable quality. E.g. the Biome linter returns horrible error messages which are a day's work to decipher.
2. Configurability. When including all those linters, configurability is very limited. At most, maybe they contain support for config files.

[hknutsen]

When it comes to super-linter, I'm getting increasingly sceptical to it. My concerns are primarily:

1. They suddenly include new linters, of more or less usable quality. E.g. the Biome linter returns horrible error messages which are a day's work to decipher.
2. Configurability. When including all those linters, configurability is very limited. At most, maybe they contain support for config files.

1. Could be "solved" by explicitly enabling the linters we want, which is something I've drafted in this PR: feat(super-linter): explicitly enable linters #809.
2. Very good point. Would this be a reason to drop our super-linter.yml workflow completely, and promote the use of linter-specific workflows instead?

[sefornes]

1. Agreed.
2. In my opinion that would be something to consider at least.

[sondresjolyst]

I think suffixing is a very good idea.

When it comes to super-linter, I'm getting increasingly sceptical to it. My concerns are primarily:

1. They suddenly include new linters, of more or less usable quality. E.g. the Biome linter returns horrible error messages which are a day's work to decipher.

2. Configurability. When including all those linters, configurability is very limited. At most, maybe they contain support for config files.

I was able to add a configuration file for Clang in Superlinter by creating a .clang-format file with rules in the .github/linters/ directory. It might also be possible to do the same for other linters.

[sefornes]

I was able to add a configuration file for Clang in Superlinter by creating a .clang-format file with rules in the .github/linters/ directory. It might also be possible to do the same for other linters.

it might, but not reliably.

[hknutsen]

An argument against suffixing: this repository contains GitHub workflows, thus tight integration with GitHub services (in this case, GHAS) is expected, i.e. a suffix would not be needed to highlight this integration.