Incremental migrations support

[hashedone]

Build on #17

The problem with migrations is their incremental structure. Having contract version 1.0, adding a migrate entry point to update to 1.1 is simple - just update the state. The problem started with the release of 1.2 with some more state changes requiring another migration - and now the contract should be able to migrate from both 1.0, and 1.1 versions. And the problem grows with time.

The idea is to be able to define migrations as simple steps, like 1.0 -> 1.1, 1.1 -> 1.2, and then the final migrate function based on the version of the on-chain contract figures out what steps are required to take to update the contract.

The concept looks like this:

struct Contract { /* ... */ }

#[contract]
impl Contract {
  #[msg(migrate, from = 1.0, to = 1.1)]
  fn migrate1_0(&self, ctx: MigrationCtx, /* ... */)  -> Result<Respons, ContractError> {
    /* ... */
  }

  #[msg(migrate, from = 1.1, to = 1.2)]
  fn migrate1_1(&self, ctx: MigrationCtx, /* ... */)  -> Result<Respons, ContractError> {
    /* ... */
  }
}

Now Sylvia should be able to generate paths to update from all the versions (1.0 and 1.1), then just match on the version of the on-chain contract, and call proper migrations (updating versions).

Additionally, there should be at least a warning (probably even an error) if there is any migration method in the contract, but none of them has "to" equal to the current contract version. Or even stronger - if there is any version with no migration path to the current contract version. It should be detectable by Sylvia and rise in compile time (panicking in constant context). The reason is, that it is very easy to forget about migration. If it is on purpose there may be two cases:

• Abandoning support for migration from older versions - in such a case, such migrations should be removed from code as they are not needed anymore
• State of the contract didn't change since the last version - in such a case, you can just change "to" of the latest migration.

For contract versioning, it is preferred to use the https://crates.io/crates/cw2 crate - instantiate entry point should have generated storing the contract name (being crate name) and contract version (using crate version in cargo). Then migrate should check this info and update it after successful migration.