Updating constructor matching for int keys

[seriousbox]

The following example works fine for mutable objects.

[MessagePackObject]
public class Example
{
    [Key(0)]
    public int IntProperty { get; set; }

    [Key(2)]
    public string StringProperty { get; set; }
}

Unfortunately, it is impossible to repeat the same thing for immutable objects. Serializing the following example throws an exception: MessagePack.MessagePackSerializationException {"Failed to serialize Example value."}. InnerException: MessagePack.Internal.MessagePackDynamicObjectResolverException {"can't find matched constructor. type:Example "}.

[MessagePackObject]
public class Example
{
    [Key(0)]
    public int IntProperty { get; }

    [Key(2)]
    public string StringProperty { get; }

    public Example(int intProperty, string stringProperty)
    {
        IntProperty = intProperty;
        StringProperty = stringProperty;
    }
}

The current implementation searches for the matched constructor according to the following logic: for each constructor parameter, there must be int key with value of the index of this parameter. So for immutable types, keys must start with 0 and have no gaps. It becomes more difficult to support changes for such types.

I propose a new implementation without breaking backward compatibility. We determine the indexes of the constructor parameters corresponding to the int keys in ascending order of their values.

This implementation does not break the current serialization logic and supports missing keys in the previous example.

[AArnott]

It's a peculiar use case, but I guess I can imagine how folks may land there. Thinking about it, I can't see how this change would present any problem.
But we do want a test for it. Can you add one?
@neuecc how do you feel about it?

[seriousbox]

But we do want a test for it. Can you add one?

Yes, I will add it today.

[AArnott]

Looks great. Let's give a couple more days for @neuecc to have a peak at it before merging.

[neuecc]

Sorry, I missed that.