refactor(ci/pr-review): use workflow_call instead of workflow_run event (v2)

[yin1999]

Description

This PR mainly switch to workflow_call instead of workflow_run event to prevent calling "PR review companion" when not necessary.

To achieve this, and take this opportunity to improve the code, the following changes were made:

1. Use pull_request_target event instead of pull_request, with the former event, the GITHUB_TOKEN has write permissions and the jobs could access GitHub secrets (we are using secrets to store the AK, SK).
2. Set the permissions of the "tests" job to read-all to avoid accidental writes to the repo.
3. Run the "PR review companion" as a spread job (named "review") in "PR test", so we could use if condition to skip unnecessary runs,
   Set the permissions of "review" job to write-all, so the deployer could create comment in PRs.
   Add secrets: inherit to inherit the secrets from the parent workflow so the reusable workflow could access all secrets. (tested in: remove some lines for test yin1999/content#8, https://github.com/yin1999/content/actions/runs/6769815012/job/18397036827?pr=8#step:10:34)
4. Use actions/download-artifact instead of js scripts, as the shared "PR review companion" workflow is a spread job in "PR test" now, we could use this action to download and unzip artifacts (simplifies the steps).

Security statement

Because the GITHUB_TOKEN generated in workflows that triggered by pull_request_target event has write permissions, we need to avoid malicious damage to the repo by the PR author.

1. Set permissions to different jobs: as the first job would run js scripts which could be modified by PR authors, set the permission of this job to read-all (as we still need the GITHUB_TOKEN to access some resouces).
2. The pull_request_target event would trigger the workflow runs with the main version of workflows (including the shared workflows - "PR review companion"). This has been tested by Onkar - Test workflow_call yin1999/content#6, and has been documented by GitHub Docs:

   Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event.

3. The workflow triggered by pull_request_target event could also access GitHub secrets. But GitHub Actions can only read a secret if you explicitly include the secret in a workflow.

Related issues and pull requests

implementation of: #28579 (comment)
Previous attempt: #28617

[bsmth]

Thanks for V2, Yin. I think we can merge later today keep an eye on CI again.

[bsmth]

Also leaving a +1, will merge this one later this afternoon and monitor builds 🔬

[bsmth]

@yin1999 @caugner you can see the new workflow in action here: https://github.com/mdn/content/actions/runs/6772741006?pr=28731

Well done 🙌🏻

[yin1999]

Thanks for your help @bsmth, @caugner.

I would like to introduce it into translated-content in a few days, until then let's check if there is any other side effects.