624: add flattenReport option for Allure2-like step behavior

[pschroeder89]

Context

Adds support for flattenReport playwright config options:
['allure-playwright', { environmentInfo: allureEnvInfo, flattenReport: true }],

flattenReport: true collapses the Playwright fixture/hook step hierarchy so attachments appear directly on the test result rather than nested inside "Before Hooks" / "After Hooks" steps in the Allure report. This matches Allure2 behavior and IMO looks cleaner. See below screenshots. Fixes #1396

Before:

After:

Checklist

• Sign Allure CLA
• Provide unit tests

[todti]

When flattenReport: true, all attachments from every hook and fixture are moved to the test root, losing their step context entirely. This creates a real UX problem as soon as a project has more than one hook attaching files.

Consider a typical Playwright setup with a beforeEach that takes a "baseline" screenshot and an afterEach that captures a "failure" screenshot plus a trace. With flattening enabled, the report shows three attachments at the root level — but they all appear as a flat list with no indication of when they were captured or which fixture produced them. If both hooks use the same attachment name (e.g. "screenshot"), the user sees two identical labels with no way to tell which is the before-state and which is the after-state. They have to open both and guess based on content.

This gets worse in real projects where multiple fixtures are composed together. A database fixture might attach a query log, an auth fixture might attach a token dump, and afterEach might attach a full-page screenshot — all with generic names like "log" or "screenshot". Flattened to the root, these become an unordered pile. The reader loses the narrative of the test: what happened first, what state the app was in at each stage, and which part of the setup or teardown produced which file.

The original nested layout — however verbose — at least answers the question "at what point in the test lifecycle was this attachment created." Flattening trades that context for a cleaner visual at the cost of making the report useless for diagnosing failures in fixtures or hooks, which is exactly the scenario where attachments matter most.

[pschroeder89]

@todti I don't disagree with Allure3's more organized structure, but it's a behavioral difference between Allure2 and Allure3 and makes it a non-starter for my team and others to make the switch. It also becomes difficult to dig through hooks / steps to find an artifact, especially if you have a lot of artifacts.
The attachments tab does alleviate this, but making this upgrade requires friction in teaching people a new UI. Flattening the report as a non-default option helps people making the jump from Allure 2 -> 3 IMO.