Include all hand-written formatters in the source generated resolver

[AArnott]

This required a great deal of (worthwhile) refactoring and fixes.

Closes #1739

[neuecc]

Thanks, I'll check soon.

[neuecc]

The changes are so extensive that I cannot carefully review the source code, but the results of running it seem to be very good!

By the way, what happened to the policy for supporting Generics that you commented on here?
#1739 (comment)

[MessagePackFormatter(typeof(MyCustomFormatter<string>))]
// ...
public class MyCustomFormatter<T> : IMessagePackFormatter<int>

Currently, it generates invalid source code that cannot be compiled.
If possible, should we make it reject such cases with a Source Generator error?

[MessagePackFormatter(typeof(MyCustomFormatter<int>))]
// ...
public class MyCustomFormatter<T> : IMessagePackFormatter<T>

This case seems to be supportable, but currently the formatter generation completely disappears.
The current changes give users the impression that custom formatters are automatically included.
Unless we either issue a warning or provide support, there is a possibility of confusing users.

As an interim policy, it may be fine to say that we don't care about Generics-related cases, but...

[AArnott]

Thanks for reviewing. And ya, sorry about the size of the PR. I too am relying on tests overall to know that we're moving forward. And yes, we surely need to add more tests for better coverage as we go.

Regarding your generics question, I still like my proposal that you linked to. I don't think it's fully implemented yet. Generics is a huge space for this and I think it'll have to come incrementally.
But regarding the particular code snippets you shared, I don't understand why you would apply [MessagePackFormatter] attributes to a formatter type. Isn't that attribute meant to be applied to a data type in order to help a resolver find the formatter?

The current changes give users the impression that custom formatters are automatically included.

That's exactly right. The only case where MessagePackFormatterAttribute is required after this change would be to bring in a formatter that is declared in some other assembly than the data type itself.

[neuecc]

I understand. No worries.

I don't understand why you would apply [MessagePackFormatter] attributes to a formatter type.

Oh, sorry, I meant to provide the following example but omitted it.

[MessagePackObject]
public class MyClass
{
    [Key(0)]
    [MessagePackFormatter(typeof(MyCustomFormatter<int>))]
    public int MyProperty { get; set; }
}

public class MyCustomFormatter<T> : IMessagePackFormatter<T>
{
    //...snip
}

[AArnott]

I think that example will do the right thing. Specifically, the 'open generic' formatter will get into the resolver as an open generic. Then specific closed generic types that are statically discoverable also make it into the resolver specifically, thus avoiding Activator.CreateInstance and allowing AOT compilers to know which formatter closed generic types to compile native code for.