Handle proxies in log parsing

[askeluv]

Background:
Quite a few contracts are proxies for a separate ("target") address, and in many cases we can't parse the event logs of these in the same way as we normally do.

Example: https://etherscan.io/address/0x49d716DFe60b37379010A75329ae09428f17118d

The above example run through the Contract Parser doesn't yield the events of the target address that we expect.

However, when pasting in the target contract 0x5d6bdeb18ba6e2be5cb87c7cfaee9cd07d000428, we get the set of events we are interested in.

But the target's BQ SQL doesn't yield any events! When we use the BQ generated for the target address, and the address for the proxy contract, we get the result we want.

Proposed solution:
Add a (possibly null) "proxy" field which when non-empty overrides the address field in our SQL template.

[medvedev1088]

The proposed solution makes sense. Additional metadata will serve as extra documentation.

An alternative is to put the target address to contract_address in table definition. It won't require changes but we lose the proxy/non-proxy metadata. @askeluv is my understanding correct?