Adopt go.work, rename modules to prep for monorepo

[mslipper]

Replaces #414 after following @protolambda's instructions.

[trianglesphere]

Was seeing withdrawals test failing - seems like it was not using an up to date version of our geth client Edit - seems like this got fixed

[codecov-commenter]

Codecov Report

Merging #441 (8c1ee9d) into main (92fccc2) will not change coverage. The diff coverage is 20.00%.

@@           Coverage Diff           @@
##             main     #441   +/-   ##
=======================================
  Coverage   51.50%   51.50%           
=======================================
  Files          70       70           
  Lines        7582     7582           
=======================================
  Hits         3905     3905           
  Misses       3154     3154           
  Partials      523      523           

Flag	Coverage Δ
unittests	51.50% <20.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
op-batcher/cmd/main.go	0.00% <0.00%> (ø)
op-batcher/config.go	0.00% <ø> (ø)
op-batcher/db/history_db.go	72.72% <ø> (ø)
op-batcher/flags/flags.go	100.00% <ø> (ø)
op-batcher/sequencer/driver.go	75.00% <ø> (ø)
op-e2e/geth.go	65.07% <ø> (ø)
op-e2e/setup.go	72.88% <ø> (ø)
op-e2e/tracer.go	66.66% <ø> (ø)
op-node/backoff/operation.go	88.88% <ø> (ø)
op-node/backoff/strategies.go	86.36% <ø> (ø)
... and 60 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 92fccc2...8c1ee9d. Read the comment docs.

[protolambda]

@trianglesphere The way it's supposed to work with go.work is that each go.mod references the other modules in the workspace by version (and we can version them independently), thus essentially we are able to freeze what each module builds with independently. But since it's not in the main branch, and not even in the correct repo yet, we need all those replace statements for Go to resolve where the module is coming from. Once the module can be resolved we can get rid of the replace statements. The go.work will then still bundle them together for cross-module editing, and in dockerfiles we make use of a slimmed down go.work with the modules involved in the docker build. This is one of the reasons why I dislike the feature-branch: it will force us to keep those replace statements around for longer, as the modules can't be resolved nicely.

[protolambda]

And regarding the replace statements:

• The reference geth statements will need to stay; each module needs to be build-able independently, same as current single module system. But we get to keep the git history separate and import paths the same, big win long term for maintainability and small diff
• The other replace statements, to modules on local path, can eventually be removed once we switch them to proper versioning + resolving via main branch in monorepo, as in my above comment.