eth/tracers: add pc field to callTracer

[iliastsa]

This PR adds a pc field to the call tracer's callframes + logs. This field is very useful for debugging transactions and mapping them to the corresponding call sites in the code.

While one could implement this as a custom JS tracer, most RPC providers do not support them (at least for lower tiers) and I feel like it's a small but useful change.

[iliastsa]

There are some failing tests ATM, not sure what's the cleanesst way to update the tests -- I've read the guide for creating tracer test files for a given TX, but I couldn't find the transaction hashes to regenerate the files.

[rjl493456442]

Any particular reason to include the PC in the emitted logs?

[iliastsa]

Same idea as the calls, map the logs to the appropriate LOG instruction in the emitting contract.

[s1na]

We need a bit more info on the purpose. It doesn't make sense to me on the first look.

[iliastsa]

The PC in the call frames helps map back to the CALL instruction of the caller. Similarly, the PC in the log objects helps map back to the LOGX instruction that emitted the log. I included the PC in both because both are "entities" in the call tracers return payload.

This kind of information is really useful when debugging transactions/working with call traces.

[rjl493456442]

It sounds like a very advanced usage, or probably just over-complicated.

Do you really need to map the logs to the execution steps?

[iliastsa]

I think it's weird to have the program counter for calls but not for the logs -- both are important entities in the trace that benefit from this information.

It's pretty standard in transaction debuggers, see this tx trace from Tenderly: https://dashboard.tenderly.co/tx/0x5a73efb84b8ba5ca688f4f6140dac5ba7222a1f980239a6942137e6a3dabe2e7?trace=0.1.8

With the program counter for the last emitted LOG, we can map it to the correct emit line in source, which is very useful when debugging transactions.