Add Quint model of Interchain Security

[p-offtermatt]

Closes: #1239

This adds a quint model of interchain Security, based on the existing TLA+ model by @Kukovec.
There are a few notable differences:

• Initializing is removed as a status - this is mostly because my goal is to use the model for MBT, and the initializing state is probably something we would skip past in the tests (also since the interactions with the initializing state aren't very meaningful in the model)
• The actions the model exposes are slightly different, e.g. time advancement and chain status advancement happen only during EndBlocks/BeginBlocks and don't happen simultaneously with other actions. This is because this makes the traces easier to test in Quint, i.e. more control over what happens when.
• I model endBlocks for both provider and consumer chains. This is because I think this is a useful extra level of implementation details that will make test traces more meaningful.

Other than that, some implementation details are different. Some are my preference, some are just due to what is more natural to write in Quint, some are to (hopefully) make traces that are easier to use.

How to review:

• Read README.md for some cursory explanations
• Run tests and sanity checks using the commands from the README. Running the invariant checks is probably too time consuming and not necessary.
• Read through ccv.qnt. Reading top-down is probably fine. What to pay attention to here: Does the code match the intention of the CCV protocol as specified here https://github.com/cosmos/ibc/tree/main/spec/app/ics-028-cross-chain-validation?
• Read through ccv_test.qnt. What to pay attention to here: Do the test traces make sense and provide fine coverage? These are supposed to be unit tests.
• Read through ccv_statemachine.qnt. This needs to not be looked at as thoroughly as the core logic in ccv.qnt, except: the INVARIANT CHECKS are important to look at. What to pay attention to: Are there more invariants that you think should be expressed here? Just generally, this would be any properties that you assume hold true for the interchain security protocol when you reason about it.

[insumity]

Suggested change

	// put an entry into sentVscPacket on the provider that corresponds to the packet we put on the consumer
	// put an entry into sentVscPacketsToConsumer on the provider that corresponds to the packet we put on the consumer

I guess the packet put on the consumer is the maturation packet?

[p-offtermatt]

the VSC packet is sent to the consumer, the consumer responds with a VSCMatured packet

[insumity]

Great work!

It might make sense to ask someone from the Quint team to also review this for Quint style, potential simplifications, etc.

[bermuell]

no need to run stopConsumers in case of error on startConsumers, right?

[p-offtermatt]

Technically not, no, but it doesn't hurt and I think it's slightly more readable like this. (Performance is not really an issue for models, we should likely radically prefer readability unless we have evidence certain things need to be faster). If you think it's currently less readable than the alternative, lmk and I will adjust

[bermuell]

Not just performance but alos readability. With constructs like this it means to me that other steps have to be executed until you return, but maybe it's just me. Up to you as it's not an issue.

[konnov]

This looks nice! Obviously, I did not try to understand the logic of CCV, but only looked at the Quint side of things.