fix #24912

[Graveflo]

#24912
Although this appears to work as far as I know the method is kinda dumb, frankly. I know the dot expression can have complexities but I have wondered a couple times why the compiler doesn't often transform the call similar to this and toss it into semDirectOp. If anyone cares to enlighten me I'll listen.

Right now this checks for tyTyepDescr explicitly but I'm thinking that it would make more sense to check if the field access is looking at a proc type, but maybe I'll commit again and check that out after I see how this goes.

[Graveflo]

not technically necessary but I isolated a bit from tparser_generator. Not 100% sure about tyGenericInst here but it doesn't seem to conflict anything else I tried. The type of the field doesn't seem to be explicitly verified this way though, which is a little weird.

[Graveflo]

Seems like both the first and the last commits will work for addressing the issue. I think the first commit is a work around, but it is simpler. The last commit delays conversions and semObjConstr until after overload resolution so that properties and such are evaluated first. It also seems to require another copyTree of the input node. Two things that are not free.

I've thought to trial overload resolution before but since it's expensive it has been better to just avoid it. Not this time. I also don't know yet if delaying semConv and semObjConstr adds another asymmetry to dot calls. Personally, I like the last commit better then the first.

[metagn]

Maybe reuse efNoUndeclared instead?

[Graveflo]

I wasn't sure about this one either. Another option might be to pass through errorsEnabled as it is in resolveOverloads and see if disabling the errors with this flag has bad side effects, but that doesn't sound great either. I'll use efNoUndeclared instead if I end up sticking with this.
edit: yea not sure how I missed that one