Fallback to the new API in xcresulttool reader

The `xcresult` reader uses the legacy xcresulttool API to extract the data from the XCResult bundle. The legacy API is more complete and easier to use than the new one. The following disadvantages of the new API come to my mind:

- Test IDs may collide
- Can't extract proper stack traces for failures
- It's more tricky to separate distinct runs of a test and associate activities with the test run (repetition/destination/parameter are mixed and interleaved)
- Bug URLs are missing (only IDs and names can be accessed)

The current state of the legacy API allows to use it by adding the `--legacy` option. The API will be removed in one of the next releases of `xcresulttool` (it ships with Xcode). The next release is expected in September 2025, so we have at least 6 months to put the new API usage in line with the legacy one.

There is also a chance the new API will receive some fixes with the next release.

Here is a brief plan of what to do:

1. Fix usage in `reader/src/xcresult/xcresulttool/index.ts`
2. Add tests
3. Add a fallback in `reader/src/xcresult/index.ts`:
```ts
import newApi from "./xcresulttool/index.js";

/* ... */

/* in parseBundleWithXcResultTool, instead of throwing an Error: */
await tryApi(visitor, newApi, context);
```

> [!NOTE]
> The new API calls are implemented in `reader/src/xcresult/xcresulttool/cli.ts`. The legacy API calls are in `reader/src/xcresult/xcresulttool/legacy/cli.ts`.

Start with reader/src/xcresult/xcresulttool/index.ts and compare its new API usage with the legacy calls in reader/src/xcresult/xcresulttool/legacy/cli.ts; the new API calls are implemented in reader/src/xcresult/xcresulttool/cli.ts. Add tests for the reader behavior, then inspect reader/src/xcresult/index.ts and verify that parsing falls back through tryApi when the new API fails.

Written by the indexing model from the issue text.