Standardize logging in ZetaClient

[CharlieMc0]

Describe the Issue
A clear and concise description of what the issue is.

Our log messages are often free-form strings that are difficult to parse at scale. There a number of values that are commonly used different parts of the code and they should be logged and specific metadata. Such as inbound or outbound tx, chain_id, etc.
The cosmos SDK already appends useful metadata in some cases but none of the custom modules or zetaclient do.

Examples (from zetaclient):

[OK] RPC status: latest block num 19441604, timestamp 2024-03-15 16:41:59 +0000 UTC ( 14s ago), suggested gas price 43756052117

This could be

{
"type":"rpc_status", 
"status":"ok",
"timestamp":"2024-03-15 16:41:59 +0000 UTC", 
"suggested_gas_price":"43756052117",
"chain_id":"5",
 }

fail to send signature to peer 16Uiu2HAkuaNDfW7s89tmiFA25YwVKWRh7Y2f7a7dACUcW8atnadT
If peer were a field we could easily track errors on a per peer basis.

{
"error":"fail to send signature to peer", 
"peer":"16Uiu2HAkuaNDfW7s89tmiFA25YwVKWRh7Y2f7a7dACUcW8atnadT", 
}

leader(zetapub1addwnpepqvzlntzltvpm22ved5gjtn9nzqfz5fun38el4r64njc979rwanxlgq4u3p8) is not reachable
Becomes

{
"error":"leader is not reachable", 
"leader":"zetapub1addwnpepqvzlntzltvpm22ved5gjtn9nzqfz5fun38el4r64njc979rwanxlgq4u3p8", 
}

Benefits

• Ability to better trace all logs related to a specific transactions or event type
• Can attribute events to specific operators or nodes
• Easier for developers to know what to include in the log and how to format it.

Example that @ws4charlie already implemented: #1790 (comment)

Expected Outcome
A consistent approach to logging that makes it easy to parse and trace logs at scale.

[CharlieMc0]

observeInTX: lasstScanned heights for chain 56 ZetaSent 39505941 ERC20Deposited 39505941 TssRecvd 39505941
As it is written it should move to debug and fix the typo in lasstScanned.

A new log should be emitted when when the three values don't match and go as a warning or error.