Trustless downtime slashing

# Problem

We would like the provider chain to be able to verify downtime evidence on its own, instead of trusting consumers, or needing evidence to go through governance. For this, we can leverage the `LastCommitInfo` in the `ClientUpdate` messages sent to the provider.

# Closing criteria

Downtime evidence for validators validating on the consumer chains can be verified on the provider chain.

# Problem details

Currently, this is how downtime works on consumer chains:

- The slashing module uses the `LastCommitInfo` [provided by Comet / Tendermint via BeginBlock](https://github.com/cosmos/cosmos-sdk/blob/b05b6fe651514c11af3d4160f7c75fbaad92d5db/x/slashing/abci.go#L16) to detect whether a validator has missed too many blocks (see [HandleValidatorSignature ](https://github.com/cosmos/cosmos-sdk/blob/b05b6fe651514c11af3d4160f7c75fbaad92d5db/x/slashing/keeper/infractions.go#L13)).
- In the current version of Replicated Security, once a validator is missing too many blocks on the consumer, a [SlashPacket is sent to the provider ](https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/validators.go#L110).
- Once a relayer relays the `SlashPacket`, the [provider jails the validator](https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/relay.go#L434) if it's not already jailed.

This approach assumes that the consumer chain is trusted, i.e., the provider doesn't verify the `SlashPacket`s besides [basic validity checks](https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/relay.go#L302). The reason is that the evidence for downtime is quite extensive, e.g., on Cosmos Hub the `Signed Blocks Window` is 10000 and the `Min Signed Per Window` is 5%, which means that the evidence of downtime consists of 9500 headers in a window.

## Suggestion

Use the `ClientUpdate` messages sent to the provider to update the client to the consumer. These messages contain consumer headers, which means they the `LastCommitInfo`. As a result, downtime on the consumer could be detected directly on the provider.

The major concern with this approach is that the client to the consumer doesn't need to be updated on every block. Thus, some consumer headers will be skipped. The detection protocol in [HandleValidatorSignature ](https://github.com/cosmos/cosmos-sdk/blob/b05b6fe651514c11af3d4160f7c75fbaad92d5db/x/slashing/keeper/infractions.go#L13) could be adapted to punish validators that have missed too many of the **_known_** consumer blocks. This means though that relayers have an impact on the downtime detection protocol. For example, let's consider a validator that misses the occasional block, but not enough to be punished for downtime (when using the original protocol). A relayer could try to attack this validator by updating the client to the consumer just with headers of blocks missed by the validator. At a first glance, this may not be a problem though as there can be many relayers (e.g., the validator could run it's own relayer). However, it is worth analyzing this scenario in more details.

# Task list

```[tasklist]
### Must have
- [ ] Check if SDK PostHandler can be used to get access to `ClientUpdate` messages
- [ ] Analyze the impact of "sampling" on the security of the downtime detection
- [ ] Adapt the logic in `HandleValidatorSignature` and add to CCV module
- [ ] E2E tests
```

```[tasklist]
### Nice to have

```