evm: Add source chain topic to TransferRedeemed and MessageAttestedTo events

[nvsriram]

This PR adds:

• sourceChain topic to MessageAttestedTo and TransferRedeemed events
• Update event emit with propagated sourceChain
• Update test and docs to account for new event signature

[djb15]

High level Q: what's the motivation for this change? Why do we need the source chain id in these events?

[nvsriram]

High level Q: what's the motivation for this change? Why do we need the source chain id in these events?

Main context behind the change is to address this issue: #504.

[djb15]

Is there the intention for integrators to potentially upgrade existing deployments?

I'd love to see a couple of tests that involve having queued transfers (both inbound and outbound) with a previous deployment, before upgrading to this functionality and trying to release the queued transfers. You may have to do this by manually writing into a slot with the old struct format to fake a queued transfer before an upgrade; that way your test doesn't have to deal with upgrades directly.

For reference, this is why I suggested you move the the new fields to the end of the structs as otherwise the reads of existing queued transfers will be borked; moving to the end of the struct should work but a test to verify would be great.