chore(op-node, op-heartbeat): Update golang-lru from v1 to v2

* op-e2e: add test option to use external eth client

This change is an attempt to allow other Optimism clients like op-erigon
to utilize the op-e2e tests in a minimally invasive way.  Almost all of
the tests are unchanged, with some small structural changes to the setup
to allow for utilization of an in process Geth, or extra-process generic
Ethereum client.

This change establishes a convention for external clients (or shims) to
follow for interoperability with these tests.  The external process shim
must accept a '--config <path>' flag.  This flag specifies a path to a
JSON file which contains necessary execution parameters. These
parameters include the data dir to use for the client, the JWT path, the
genesis JSON path, and the chain ID.

Utilizing the external binary is is generally more resource intensive
than the in process Geth path, but, utilizing parallelism the test suite
there is no noticable difference in execution time between the in
process and an extra-process op-geth.

This commit simply performs the wiring, while the next commit will add
an op-geth consumer and wire into CI.

* op-e2e: add basic external geth runner

This commit adds an example external shim which utilizes the code in the
previous commit.  It also integrates it into the Makefile and into CI
(which unfortunately does not use the Makefile).

To utilize this geth runner locally you can execute:

  make test-external-geth

from the op-e2e directory.  See the README.md included in external_geth
for more details.

---------
Co-authored-by: Jason Yellick <jason@enya.ai>

op-challenger: Add basic metrics & pprof setup

# Conflicts:
#	op-challenger/fault/service.go

chore: Rebase PR 5329

op-challenger: Initial support for playing multiple games

build(deps-dev): bump patch-package from 6.4.7 to 8.0.0

chore(common-ts): Upgrade all npm dependencies

This adds metrics & pprof to the op-challenger. I had to add a default config
option to the metrics & pprof in order to make the tests work (because it
verifies that the result of the CLI parsing is as expected when compared to
an config struct which is constructed).

This also had to modify how the challenger stores its version information
because we include that information in the metrics when we record that it is
up. Unlike the proposer & batcher, the challenger has a different initialization
flow which does not easily make the version information accessible.

chore: DisputeGameFactory Styling Touchups

contracts-bedrock: add deploy config validator

feat(ctb): Pack `GameType` in DGF's `GameId` type

contracts-bedrock: small cleanups in deploy scripts

op-node: batch_decoder: Parallel tx fetching