nobridge flag for incompatible tokens

[AlexBHarley]

In my opinion the main purpose of this repository is to provide an index of StandardBridge compatible tokens. That is, tokens compatible with the IOptimismMintableERC20 or IL2StandardERC20 interfaces.

What we have instead is many 3rd party bridge tokens (Layer Zero OFTs, Wormhole NTTs, etc) that are not compatible with the native StandardBridge contracts but specify a bridge override. In my opinion these should be specify the nobridge: true flag so they don't show up in the generated optimism.tokenlist.json file.

• If bridge frontends relying on this generated file correctly interpret the bridge override, the UX is that tokens show up but are not bridgeable

• If bridge frontends relying on this generated file don't account for the bridge override, losses can occur. Here are a few examples of this happening,

  • 18 wstETH loss https://etherscan.io/tx/0x6c200205fc933c345cd7813e758934031478176e961ea56a1b8761b8534f761b
  • 25 wstETH loss https://etherscan.io/tx/0x14c77dc75bf19e5eba3c6c5a853ad34430368f0746b4589d3ebfbbc57b8147b7
  • $250,000 in SPX loss https://etherscan.io/tx/0x99092472f2c59e5f0881ee0560270761b84d10620daec2b9c08eae274537304f

Neither of these cases are desirable so I'd prefer if these were just automatically filtered out. I believe the CI checks used to enforce this, but they've been slightly altered and now if a bridge override is present it still allows adding tokens with a warning.

[wbnns]

Concept ACK

@AlexBHarley Thanks for raising this issue 👍

[wbnns]

Cc: @hamdiallam @nitaliano