feat: allow readers to consume directories

[delatrie]

This is a prerequisite for #84.

Context

Currently, Allure3 readers can only consume separate files. The new XCResult reader consumes test result bundles, which are directories.

After some discussion, we've decided to allow readers to consume directories in addition to separate files.

Currently, the algorithm for processing directories is:

1. List the directory.
2. Feed each file to readers.

This PR changes it to be:

1. Feed the directory to readers.
2. If one of them successfully consumes it, the process is done.
3. Otherwise, list the directory and feed each path to readers.

Note, that a path in step 3 now can also be a directory (which would've been skipped previously).

Interface changes

The new algorithm requires some adjustments to the reader interface. The main interface now looks like this:

export interface ResultsReader {
  read(visitor: ResultsVisitor, path: string): Promise<boolean>;
  readerId(): string;
}

The read function now takes a path instead of a ResultFile instance. This is because a directory can't be properly represented by ResultFile. The downside is that we can't feed an instance of BufferedResultFile to the read method but we only used this in one test (which was easy to adjust). Other callers directly translate a path into a PathResultFile instance.

The PR also introduces two new helper base classes for reader implementations: FileResultsReader and DirectoryResultsReader. These classes check the path before calling the underlying abstract method (readFile and readDirectory respectively), which a sub-class needs to implement.

All existing implementations were adjusted to be sub-classes of FileResultsReader. The only difference now is that read is now a function instead of lambda and will require bind if assigned to a variable (which we don't do anywhere).

Dependency changes

A new dev dependency archiver is used to attach directories as .zip archives to Allure Report in directory reader tests. It will be useful for debugging readers like xcresult.

Other changes

• disable fileParallelism in the vitest config of web-components; it caused flakiness due to a circular reference between TS config files via extends and references fields. This is a workaround until we update to vitest v3 or fix the configs. More details here.
• eslint fix in config.test.ts
• add missing await in config.test.ts

[delatrie]

After some discussion we've decided to move toward input directory classification. For now, xcresult reader should be a special case handled bycore/readDirectory. We'll figure out how to abstract it away later.