Retrieve SARIF errors and warnings correctly

[bdovaz]

With @nvuillam's request I have:

• Return the number of warnings (which it didn't do)
• Correct the calculation of counting the errors or warnings according to: https://github.com/microsoft/sarif-tutorials/blob/main/docs/2-Basics.md#results
  • If the property “level” exists in the object “result” (some linters like gitleaks does not fill it) it counts the number of objects in the array “locations”.
  • If the property “level” does not exist, it only counts the results for the level “warning”, because by default in the specification it is set like this: https://json.schemastore.org/sarif-2.1.0.json
• Add sarif to cli_lint_errors_count in json scheme (was implemented in code but not added to schema)
• Add sarif to cli_lint_warnings_count in json scheme
• Share in two functions (regex and sarif) this logic

There are linters that do not fill out the SARIF level field:

llaville/sarif-php-converters#1 (Fixed!)

pmd/pmd#5573 (Fixed!!)

anchore/grype#2511 (Fixed!!)

gitleaks/gitleaks#1858

In these cases if they do not fill in the “level” field as I have put in the first message, according to the specification the default value is “warning” so it will be reported as such.

There are other cases Python Bandit that fills levels that we do not show in the reporters like “note” level, in this case I make it to be interpreted as warning that is the closest one.

That is, before this PR everything was interpreted as error, now:

• If they do not fill in the property “level” it will be reported as warning as described in the specification.
• If they fill it as “error” it will be reported as error.
• If they fill it as “warning” it will be reported as warning.
• If they fill it as “note” it will be reported as a warning because it is the closest one we have in the reporters.

[github-actions]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ API	spectral	1		0	0	1.71s
⚠️ BASH	bash-exec	6		1	0	0.02s
✅ BASH	shellcheck	6		0	0	0.19s
✅ BASH	shfmt	6	0	0	0	0.23s
✅ COPYPASTE	jscpd	yes		no	no	2.97s
✅ DOCKERFILE	hadolint	131		0	0	30.77s
✅ JSON	jsonlint	20		0	0	0.21s
✅ JSON	v8r	22		0	0	11.79s
⚠️ MARKDOWN	markdownlint	269	0	306	0	21.42s
✅ MARKDOWN	markdown-table-formatter	269	0	0	0	142.58s
⚠️ PYTHON	bandit	222		67	0	5.28s
✅ PYTHON	black	222	0	0	0	4.6s
✅ PYTHON	flake8	222		0	0	1.99s
✅ PYTHON	isort	222	0	0	0	0.68s
✅ PYTHON	mypy	222		0	0	12.75s
✅ PYTHON	pylint	222		0	0	32.5s
✅ PYTHON	ruff	222	0	0	0	0.21s
✅ REPOSITORY	checkov	yes		no	no	35.42s
✅ REPOSITORY	git_diff	yes		no	no	0.16s
⚠️ REPOSITORY	grype	yes		30	no	30.46s
✅ REPOSITORY	secretlint	yes		no	no	8.86s
✅ REPOSITORY	syft	yes		no	no	2.35s
✅ REPOSITORY	trivy	yes		no	no	11.89s
✅ REPOSITORY	trivy-sbom	yes		no	no	19.84s
✅ REPOSITORY	trufflehog	yes		no	no	7.39s
✅ SPELL	cspell	730		0	0	16.58s
⚠️ SPELL	lychee	351		36	0	70.02s
✅ XML	xmllint	3	0	0	0	0.65s
✅ YAML	prettier	160	0	0	0	3.8s
✅ YAML	v8r	103		0	0	14.56s
✅ YAML	yamllint	161		0	0	4.74s

See detailed report in MegaLinter reports

[nvuillam]

Looks good to me :)
To merge one CI is ok :)