Possible schema hashing false mismatch due to unstable msgpack map serialization

While working on the task, it was discovered that msgpack does not guarantee the order of elements when serializing map.

Input for example:

{
  indexes = { {
      parts = { {
          exclude_null = false,
          fieldno = 2
        } }
    },
    [0] = {
      parts = { {
          exclude_null = false,
          fieldno = 1
        } }
    }
  }
}

Serializing output on different hosts:

��indexes���parts���exclude_null§fieldno��parts���exclude_null§fieldno

��indexes���parts���fieldno�exclude_null���parts���fieldno�exclude_null�

It can be seen that the fields exclude_null and fieldno have different order on different hosts.
Since this is used to get the hash and determine if the schema needs to be reloaded, we may get a false schema mismatch problem:

https://github.com/tarantool/crud/blob/781ef16fc3ab725cf4c0720b9f67def80b32f785/crud/common/schema.lua#L139

It should also be noted that a similar calculation approach is used in other places:

https://github.com/tarantool/crud/blob/781ef16fc3ab725cf4c0720b9f67def80b32f785/crud/common/sharding/utils.lua#L31

Start with the schema hashing logic at crud/common/schema.lua#L139, then compare the similar calculation in crud/common/sharding/utils.lua#L31. Reproduce the differing msgpack map order shown in the issue and verify that equivalent schemas produce the same hash across hosts without unnecessary reloads.