build: implement visual regression testing with @web/test-runner

[kyubisation]

This PR sets up the basic configuration for visual regression testing with @web/test-runner.

web-test-runner.config.js contains a new test group, which is only activated when explicitly called with yarn test:visual-regression. This test group introduces a new file pattern *.snapshot.spec.ts, which contains the visual regression tests.
Additionally, there is a new GitHub Actions workflow, which runs the visual regression tests and saves failed screenshots in an artifact. This artifact is then downloaded in the secure workflow, which adds an in_progress check, if any failed screenshots exist.

We do not want to save the snapshot png in the repository, as this would bloat it considerably. Due to this, we use containers as an external storage of the png files. The process works as follows:
Each continuous integration run on our main branch creates/updates a container baseline (https://github.com/lyne-design-system/lyne-components/pkgs/container/lyne-components%2Fvisual-regression). For any other CI run (in the secure context) this container is used as a service and the png files are downloaded when needed.
Additionally, the baseline image is hosted at https://lyne-visual-regression-baseline.app.sbb.ch/ in order to enable local visual regression testing.

As for local visual regression testing; To avoid diffs between operating system browser differences, visual regression testing is only directly run in a Linux environment. If it is executed in any other OS, it will try to run it in a container to prevent OS differences showing up in the snapshots.

[TomMenga]

Some elements are still obscure but I have a general idea of the implementation.
I'm not sure how the remote baseline is used and why we need to use a container to run the diff locally (but I'm sure there is a reason)

Some discussion topics:

• I'm a bit scared of the exponential nature of the number of cases (P1 * P2 * ... * Viewport * browsers * 3 (default, focus & hover))
  • Pro: covers almost every use case
  • Con: grows very quickly and requires an "implementation" for each component
• Alternatively, we could reuse the stories template?
  • Pro: we would avoid most of the .snapshot.spec code
  • Con: not exhaustive like combining each case

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 41.17647% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 93.13%. Comparing base (e6397df) to head (f5256ad).
Report is 91 commits behind head on main.

❗ Current head f5256ad differs from pull request most recent head 42cf6c2. Consider uploading reports for the commit 42cf6c2 to get more accurate results

Files	Patch %	Lines
src/components/core/testing/test-setup-ssr.ts	9.09%	20 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2624      +/-   ##
==========================================
- Coverage   93.18%   93.13%   -0.06%     
==========================================
  Files         316      315       -1     
  Lines       25389    25323      -66     
  Branches     2063     2071       +8     
==========================================
- Hits        23660    23585      -75     
- Misses       1696     1705       +9     
  Partials       33       33              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kyubisation]

Some elements are still obscure but I have a general idea of the implementation. I'm not sure how the remote baseline is used and why we need to use a container to run the diff locally (but I'm sure there is a reason)

Some discussion topics:

• I'm a bit scared of the exponential nature of the number of cases (P1 * P2 * ... * Viewport * browsers * 3 (default, focus & hover))

  • Pro: covers almost every use case
  • Con: grows very quickly and requires an "implementation" for each component

• Alternatively, we could reuse the stories template?

  • Pro: we would avoid most of the .snapshot.spec code
  • Con: not exhaustive like combining each case

Thanks for the review and feedback!
We have reduced the amount of snapshots by being a bit more selective.
Additionally I updated the PR comment to better describe the container use cases.
I think it makes sense to reuse story templates where it is reasonable, but I assume it will depend on the case.