PolyType.Roslyn should not require so much re-invention to use like polytype's source gen

[AArnott]

Some TypeDataModelGenerator class overrides in the Parser class like ResolveConstructors is anything but trivial, and likely has policy that changes over time. This really isn't something I want to source-copy into my own analyzer.

I respect that you want PolyType.Roslyn to allow others to use this with their own attributes, etc. But could you either:

1. provide default behavior that matches polytype while leaving the methods virtual, OR
2. provide a derived type that your source generator uses such that I can consume it?

[eiriktsarpalis]

So effectively move the Parser class to PolyType.Roslyn? I think that would be doable. Of course, I wouldn't ever be able to guarantee API stability given that it would be surfacing source gen implementation detail on a library but it feels like this might be acceptable in this context.

[AArnott]

I wouldn't worry about cross-version compatibility for this library much, since it never has to work with clients expecting different versions.
I had Copilot develop a proposal to deliver on this, so if you're willing, I'll have it prepare a PR.

[AArnott]

Here's the copilot changes. I haven't looked over it carefully and I wonder if that would be valuable since ultimately you probably want to steer this. :) But here's a potential resource for you: AArnott#4

[eiriktsarpalis]

I would probably just copy over the Parser class and the model types in PolyType.Roslyn wholesale. The only challenging part is coming up with good names that differentiate the two types. They would probably need to be segregated into different namespaces as well.