Fixed type inference for 'set` and 'tuple'

[beef331]

Closes: #18826
Also the following no longer crashes the compiler:

proc b(val: int or float): set = 
  when typeof(val) is int:
    {10u8, 3}
  else:
    {'a', 'b'}
assert typeof(b(10)) is set[uint8]
assert typeof(b(10.0)) is set[char]

[Araq]

The crash is bad of course but why should this code compile? Where's the merit in allowing partially specified return types? Either write the return type or use auto. Type classes are constraints for parameters, not for return types.

[ho0ber]

Where's the merit in allowing partially specified return types? Either write the return type or use auto. Type classes are constraints for parameters, not for return types.

Yeah, my perspective as someone new to Nim is that there was nothing telling me that using a tuple return type was "wrong", especially because it had worked in every prior circumstance (where I was returning tuple variables). It was quite baffling to have the code work fine if I added a line and assigned my return value to a tuple, vs returning that value directly.

I think that either a fix like this PR OR a more expressive compiler error would have made this less difficult for me. I guess the alternative is to just disallow using tuple as a return type altogether so it doesn't seem to work fine in some circumstances if it's not idiomatic.

I don't think this is likely to trip up anyone but beginners, but this is the kind of error that makes beginners think a language isn't ready for serious use; it seemed odd that the same behaviors wouldn't apply to returns that apply to assignment.