Fix proxy detection for EIP1967 when storage slot is only referenced in creation code

[manuelwedler]

Fixes #1928

• Updates whatsabi to 0.20.0 which is the version that supports this kind of proxy
• Uses creation bytecode for detection if available in v2 lookup

[kuzdogan]

Looks ok but couple comments and questions about the code in general:

1. I notice this comment, do we have an issue for this?

  // TODO:
  // The proxy detection will be integrated into the verification process,
  // and the proxy detection result will be stored in the database.
  // When we have this, we will only need to resolve the implementation address here,
  // and don't need to query the onchain runtime bytecode.

and this

// TODO:
// onchain bytecodes are a temporary solution for running the proxy detection inside the getContractEndpoint handler.
// Remove onchainRuntimeBytecode and onchainCreationBytecode when proxy detection result is stored in database.

2. Are we making sure the current StorageService is a DB and not the legacy filesystems? We use

  const contract = await services.storage.performServiceOperation(
    "getContract",
    [req.params.chainId, req.params.address, fields, omit],
  );

What happens if it runs a RepoService.getContract function? Ie. is there a way we make sure APIv2 endpoints are only used by the DB storages services?

[kuzdogan]

Can the onChainBytecode be empty string ""? If so it's better to use || instead of ??. ?? checks only for null and undefined, || checks all falsey values.

[kuzdogan]

Looking back at this again, I don't understand why contract.proxyResolution has onchainBytecode fields. Why do we have them in that object? Why don't we use contract.onchainRuntimeBytecode etc. directly?