fix: detect conflict when generic is not of the same base type

[Daniel-Vetter-Coverwhale]

I initially thought that automatically generating wrapper types would be nice (#937), and I still think that it would, but I also now realize that it's much harder than I anticipated, at least for me with my limited knowledge of the repo/codegen flow. Using this I was able to know when I would need to wrap types with new names, but I wasn't able to figure out how to wire them up correctly to the operations so that they got generated out. And that's not even mentioning that we'd probably want to deduplicate them at some later point

This alone seems like a good start though, as it at least notifies us that there is a conflict. My specific issue was with a custom Date type that was not required, so it became OptDate just like another date field that was a string with format date and also not required. So I wound up with conflicting OptDates and no error because they both were generic.

I'm pretty sure this check could be better, but it does solve my case by alerting me to the problematic type conflicts.

[codecov]

Codecov Report

Patch coverage: 94.44% and project coverage change: +0.03 🎉

Comparison is base (c9a1eb9) 72.35% compared to head (c248744) 72.39%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #941      +/-   ##
==========================================
+ Coverage   72.35%   72.39%   +0.03%     
==========================================
  Files         190      190              
  Lines       14563    14580      +17     
==========================================
+ Hits        10537    10555      +18     
  Misses       3500     3500              
+ Partials      526      525       -1     

Impacted Files	Coverage Δ
gen/tstorage.go	64.70% <94.44%> (+4.90%)	⬆️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ernado]

Hi, thank you for your PR and for your effort to figure out how our pretty complicated codegen works.

Sorry that it is so hard, probably we should add more architectural docs to make contribution easier.

Can you please add examples to _testdata directory, ideally at least one to "positive" subset that is failing for main branch, but is fixed by your PR.

This will greatly help us to review your code.
Thank you in advance!

Also, you can ask about internals in telegram chat, probably we can help you better understand our codegen shenanigans.

[ernado]

Ref: #1148