Update workflows to support fork PRs

[jprochazk]

What

Part of #1994

This duplicates certain workflows and sanitizes them to not use secrets. Anything that uses secrets must run on pull_request_target.

A similar attempt was made in #1991

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[jprochazk]

This introduces another bundle of joy for anyone working on our CI:

• Every check must separately be added to the contrib workflows, introducing an awful case of duplication
• Every workflow that runs on pull_request must be sanitized properly, unless it uses the if repo_owner == rerun-io check (which we have to think about now)
• Every contrib workflow must be confirmed to work by making a contribution from a different account, and for that to even be possible, it must be merged into main first

[jleibs]

The overall concept seems sound. A few questions regarding possible refactors, but we can also punt those until we have more time if they are too much work.

[jleibs]

These have to be on a per-job basis rather than just skipping the whole workflow?

[jprochazk]

I think so, or at least I couldn't find a better way to do this. We need to know if the PR comes from within the rerun-io organization, and there doesn't seem to be a built-in way to do this on pull_request events.

[jleibs]

Doesn't really matter, but I feel like it would be more obvious to have these in on_pull_request following the non-contrib sections.

[jprochazk]

I wanted the name of the workflow to be different from the usual Pull-Request, because GH generates the full name of the job by concatenating the name with the parent workflow

[jleibs]

I'm a bit worried about maintainabillity here.

How much worse would it be to add a workflow_call parameter such as:

      CONTRIB:
        type: boolean
        required: false
        default: true

And then parameterizing the job instead of forking.

[jprochazk]

I tried it, and found it to be significantly worse. These if checks get lost in the mass of yaml. I think the duplication makes this slightly more maintainable.

[jprochazk]

Merging so I can test an external contribution