chore: module-renaming workflow inverts between libevm and geth

[ARR4N]

Why this should be merged

Originally I'd planned on doing an upstream sync by running the rename workflow on the incoming commit and then merging it to main however this resulted in hundreds of merge commits that were solely due to Go imports. Renaming the module from ava-labs/libevm to ethereum/go-ethereum removed 90% of conflicts (H/T @darioush). The module will then need to be named ava-labs/libevm again, so the commit history will probably¹ look like this after an update:

---
config:
  gitGraph:
    mainBranchName: main
    parallelCommits: true
---
gitGraph TB:
    branch geth order:2
    commit id:"geth@v1.15.2"
    checkout main
    commit id:"libevm@v1.13.14"
    branch sync/v1.15.2
    commit id:"[AUTO] rename to ethereum/go-ethereum"
    merge geth
    commit id:"[AUTO] rename to ava-labs/libevm"
    checkout main
    merge sync/v1.15.2 id:"libevm@v1.15.2"

Loading

How this works

The current module name is determined with go list -m and the rename from/to patterns are no longer hard-coded.

How this was tested

Inspection of runs and resulting branch. Although these were the bc8e501 workflow, the only other commit in this PR is cosmetic (as seen in this run to create f2cecaf).

1. Run on main @ d32c7e0 changes from libevm to go-ethereum:
   a. Run
   b. Commit
   c. Created branch arr4n/auto/test-invertible-rename
2. Re-run on arr4n/auto/test-invertible-rename changes back to libevm:
   a. Run
   b. Commit
   c. Auto-generated branch is identical to main at the time of running

Footnotes

1. Specifics of and rationale behind the merge strategy are beyond the scope of this PR. ↩