Story files tests / Accessibility tests: use a Web Test Runner Plugin instead of individual files

[florian-sanders-cc]

Fixes #731
Fixes #963
Fixes #854

What does this PR do?

• Removes all component test files that only contained a11y tests,
• Removes a11y tests from component test files that contain other unit tests,
• Makes WTR run tests on every story file:
  • adds src/components/**/*.stories.js to the list of files to be handled by Web Test Runner. They are then transformed into test files by a plugin.
  • adds a test-stories plugin that:
    • tells the Web Dev Server used by WTR to import a virtual .stories.test.js file instead of the story file,
    • produces the content of the .stories.test.js file when it is requested by the browser and serves it,
    • the content of the test file is fairly basic: import actual stories and pass them to the testStories helper that will loop over all stories to run tests (at the moment a11y tests to be specific, but later on we'll add visual regression tests in there).
• Merges getStories & testStories helpers into a single file because we never use them separately (testStories is the only one using getStories so they may as well be in the same file).
• Changes the logic to exclude stories from tests:
  • we used to provide a list of stories to ignore because we manually created test files,
  • now all stories are tested by default and you can opt out of automated testing from the story options,
    • docs have been adapted to reflect these changes,
    • check the refactor(stories): disable some accessibility tests and rules to see how it looks within story files,
    • this is very close to what @pdesoyres-cc suggested in test: discuss the best strategy to ignore some a11y tests #731.
• Experiments with groups to make it easier to focus on unit tests (outside of components) or component stories tests, or component unit tests.
• Filters out ResizeObserver logs + adds export conditions so that we pull prod dependencies instead of dev (this way we test the components in the same conditions as when they are published).

How to review?

Tip

It's a good idea to start by checking the updated docs about stories (Manage accessibility tests section at the very bottom) in the preview.
This way you'll get some overview of the API before diving in the actual implementation of that API.

• Check the commits,
  • you don't really have to check the refactor(tests): remove component test files but if you do, the only thing to look for is that files removed only contained a11y tests and nothing else.
• Run the tests locally, play with the groups,
• The whole team should review since it impacts our dev workflow.

Things to be discussed

There are many things that could be discussed.
Feel free to weigh in about naming / architecture / (de)coupling.
For instance, I didn't try to make the plugin more generic so it could be used by other projects. I focused on our needs and that's it. The idea & principles are very close to what we do in storybook to support markdown with frontmatter.

If needed, we can organize a meeting about this PR to discuss and decide on some specific implementations.

[github-actions]

🔎 A preview has been automatically published : https://clever-components-preview.cellar-c2.services.clever-cloud.com/accessibility-tests/refactor/index.html.

This preview will be deleted once this PR is closed.