fix: don't interfere with stdout/stderr in linter

`php -l` is inconsistent in it's return codes, as it may exit 0 on
correct code, but while encountering parse errors, it may end up with
0 or 255, but the message is sent do `stdout` instead of `stderr`. This
may seem irrelevant but have some serious implications.

If we decide to ignore `stdout` (which is better for readable job trace),
we may end up with error exit code but without error message, impossible
to detect. On the other hand, if we send all `stderr` output to
`/dev/null`, we consequently ignore most of errors produced by linter,
thus we think our code is valid, which may not be true.

To keep best of both worlds (succinct output and clear error messages)
rely on filtering output, to contain only those lines, which may inform
us about errors and ignore all "No syntax errors" lines as it may be the
most predictable way.

Signed-off-by: Bart Jaskulski <bjaskulski@protonmail.com>

includes/tests/lint.yml

@@ -2,7 +2,7 @@
   stage: tests
   script:
     - composer install --no-dev
-    - find -name '*.php' -print0 | xargs -n1 -0 -P16 php -l 2>/dev/null
+    - find -name '*.php' -print0 |xargs -n1 -0 -P16 php -l |grep -v "No syntax errors detected"
 
 lint:8.1:
   <<: *lint-tmpl