feat: Added in link validation

[ControlCplusControlV]

Description

Added in a go tool which looks up a given address and tells you where it is from and what it actually is, right now it uses the superchain-registry currently installed in lib as a submodule. It also has the ability to link out to github where that address comes from, with line numbers.

I have then added it to our scripts so that when we generate a state diff all addresses are now properly linked.

Tests

Now after running

006-opcm-upgrade-v300

SIMULATE_WITHOUT_LEDGER=1 just --dotenv-path $(pwd)/.env --justfile ../../../nested.just simulate child-safe-2

The state diff produced is properly linked

### [`0xf272670eb55e895584501d564AfEB048bEd26194`](https://github.com/ethereum-optimism/superchain-registry/blob/4791054602a56a72705ac7ecd601433c9c955791/superchain/configs/sepolia/base.toml#L60)  (SystemConfig) - Chain ID: 84532

- **Key:**          `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
  - **Decoded Kind:**      `address`
  - **Before:** `0x760C48C62A85045A6B69f07F4a9f22868659CbCc`
  - **After:** [`0x340f923e5c7cbb2171146f64169ec9d5a9ffe647`](https://github.com/ethereum-optimism/superchain-registry/blob/4791054602a56a72705ac7ecd601433c9c955791/validation/standard/standard-versions-mainnet.toml#L9)
  - **Summary:**           ERC-1967 implementation slot
  - **Detail:**            Standard slot for storing the implementation address in a proxy contract that follows the ERC-1967 standard.

**<TODO: Insert links for this state change then remove this line.>**

  ---

Please let me know if there is a better way to test this, I also know I will need to make changes to the justfile for the installation of it as a go tool / building the binary.

Additional context

Linking was taking very long when making upgrades and so I cut it down in size.

Metadata

[maurelian]

@JosepBove IIRC you wrote something similar, but maybe it's not running in CI at the moment?

[blmalone]

I think the general approach should be:

1. Raise an issue with a clear problem statement and proposed spec
2. Get buy-in
3. Then raise a PR

(That said, if the problem is well understood, going straight to a PR is fine.)

A few quick thoughts on this PR specifically:

1. Automatically linking to addresses is a nice touch.
2. I'd prefer not to add the Go toolchain to the new superchain-ops repo.
3. For Foundry FFI, we've been using bash scripts consistently.
4. This should include unit tests.
5. I'm a bit concerned about maintainability. This is tightly coupled to the scr, which will likely mean having to do a bunch of work to keep it functional.

[mds1]

Closing as stale for now