Multi-version support for CometBFT v0.38

[thanethomson]

Description

Since the CometBFT v0.38.0-alpha.1 release has been cut and it appears as though the API is mostly stable, we should look at implementing support for v0.38.0 when the final release comes out later in Q2 of 2023.

Definition of "done"

When tendermint-rs supports CometBFT v0.34, v0.37 and v0.38.

### Tasks
- [ ] https://github.com/informalsystems/tendermint-rs/pull/1312
- [ ] https://github.com/informalsystems/tendermint-rs/pull/1317

[mzabaluev]

I started off a branch by generating the v0_38 module in tendermint-proto alongside v0_34 and v0_37 and using the newly generated code in appropriate places.

The main items of work here appear to be:

• [x] Add support for v0_38 protobufs in tendermint. (https://github.com/informalsystems/tendermint-rs/pull/1312)
• [x] Look over changes in the RPC protocol and the need to introduce a new RPC dialect. As a minimum, 0.38.x versions should be recognized in dialect detection. (#1317)
  • [x] Obtain test fixtures for a 0.38.x node and use them to verify RPC encodings.
• [x] Adapt support for ABCI applications in tendermint-abci to the latest version, in line with previous changes in #1193. (https://github.com/informalsystems/tendermint-rs/pull/1312)

[mzabaluev]

Here are my notes on the RPC adaptation.

The main difference is a few fields in the response to /block_results: the event lists in begin_block_events/end_block_events have been replaced with a single list in finalize_block_events. Another, smaller change is the deliver_tx field, renamed to tx_result in the response to /broadcast_tx_commit.

I have started out, again, on a "clean" solution: statically separate, versioned endpoint traits to expose the differences at the type level. But again, the impact on the consumer does not seem to be worth the weight of these few changes. I think it's better to expose both old and new fields side by side on the API types representing RPC endpoint responses.

Specifically, endpoint::block_results::Response would have its begin_block_events and end_block_events fields only populated with values when a pre-0.38 node is queried, otherwise these fields will have empty vectors, but finalize_block_events will have the 0.38+ event data. In time, the former two fields will be deprecated as we drop support for older versions of the protocol.

[mzabaluev]

Similarly, in WebSocket subscription events, there may be a result_finalize_block field alongside result_begin_block/result_end_block.