Add API-level proxy detection and implementation resolution

[manuelwedler]

Closes #1655

This implements an API-level proxy detection as in #1655 by making use of the whatsabi library. A few explanations about this PR:

• I had to add two methods to the SourcifyChain class for making it compatible to the whatsabi library as a provider, and for being able to resolve the implementation addresses of DiamondProxy contracts.
• I added a proxyResolutionError to the API response for the case that the proxy resolution fails. This could be due to an unresponsive RPC for example. In such a case, I still want to respond successfully to the user but let them know why the proxy fields are not there.
• Related to proxies: Multiple instances of the same resolver shazow/whatsabi#142:
  • A FixedProxyResolver was returned in a lot of cases where actually a library was called by a DELEGATECALL. I decided to only support EIP1167 proxies for this resolver. Any other FixedProxy would be a non-standardised proxy (or even a library). So in case a FixedProxyResolver is detected, we check explicitly for the opcodes standardised in EIP1167.
  • I saw a few cases where multiple resolvers were returned, and also some cases where a resolver resolves to 0x0. The latter was for example the case for a factory contract which deploys EIP1967 contracts. Therefore, I iterate over the returned resolvers and return the first implementation address which is not 0x0.
• This feature is only added to the /check-all-by-addresses endpoint and not the check-by-addresses endpoint, because in the latter the chainIds array does not contain objects.

Remaining issue (non-blocking)

There is still a problem left from shazow/whatsabi#142:
A contract that embeds a proxy (as for example a factory contract) could falsely be detected as a proxy.

A first proposal to solve this is to not consider contracts with CREATE/CREATE2 opcodes as proxies. However, this will not catch all contracts that only embed proxy bytecodes, and also exclude factory contracts that could be at the same time a proxy.

Edit: We decided that this problem is not a blocker for this PR. IMO, it is good to get this out and test it. The proxy data won't be persisted in our database with this change, so before we persist it we might be able to improve the proxy detection.