try weakened distinct

[Graveflo]

offshoot of #24964

I first tried to make importc types a new kind of type and allow it to accept it's Nim equivalent, but this was difficult, took a lot of time and in the end I couldn't get it to fully work. The main problem was that Nim converts types to and from importc types regularly, so this new type had to do a bunch of odd things to not break those behaviors.

Trying this out was much easier since I could just re-use most of the logic for distinct however there are some concerns I have at this time:

• sameType proc might need some attention
• I haven't looked at the generated C code so it might be inefficient
  • I'd be interested to see seq[T] varients and such
• ~Conversions are still needed in some situations with this where they weren't before, but so far I haven't seen anything that looked like it should work. For example a previous automatic conversion from a non literal int to cint needed a patch, but why did that work without a conversion in the first place?~
  • ~primitive conversion semantics probably have to be looked at again but I forget where that is / how that works~
• this accepts the type both ways with equal penalties and such and I haven't really thought about if that is a mistake

in general I think that something like

type
  myType {.importc:"int".} = int32

always must mean that the backend will map Nim's representation of int32 to int, if this is not a guarantee then something like nodecl and a proper exclusive definition has to be used to make the type opaque and I don't think there is a way around that.