ci: allow custom runners usage in the Go Test workflow

[galargh]

This is a follow-up to the discussions we've been having at https://ipdx-workspace.slack.com/archives/C03KLC57LKB/p1730963666791569

I forgot about this limitation before. In this PR I pointed the go-test at the fork of https://github.com/ipdxco/unified-github-workflows that lives in filecoin-project org https://github.com/filecoin-project/unified-github-workflows. By doing that, we'll be able to set up custom runners for the workflow via the repo config vars.

What's also worth noting is that https://github.com/filecoin-project/unified-github-workflows is kept up-to-date automatically by https://github.com/ipdxco/unified-github-workflows/actions/workflows/sync-forks.yml (so it doesn't introduce any additional manual maintenance burden whatsoever).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.26%. Comparing base (c92e6d4) to head (f8eb94e).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #750      +/-   ##
==========================================
- Coverage   69.80%   69.26%   -0.54%     
==========================================
  Files          74       74              
  Lines        7497     7497              
==========================================
- Hits         5233     5193      -40     
- Misses       1856     1887      +31     
- Partials      408      417       +9     

see 4 files with indirect coverage changes

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[masih]

I am curious as to why only go-test workflow is updated. Do we want to consistently use the workflows from filecoin-project fork?

[galargh]

Not necessarily, we only need to use workflows from the fork in filecoin-project in the workflows where we want to use custom GitHub runners.

The fork and the origin are kept identical automatically. The fork only exists to overcome the limitation that disallows usage of self-hosted runners in reusable workflows that live outside the org.