fixed type inference of FieldSetter to allow override

[mgronover]

Ticket: #668

Customer may want to override the type of a FieldSetter This can be achieved with this PR.

[mgronover]

This commit is cherry picked into the branch "datev-loon-staging-20213" (right now).

[mgronover]

@arimer both points were intended by customer ticket. According to the type cast: well it is safe to write node:Type in this case, are there concrete reasons to do so?

[alexanderpann]

I would also argue that we should not use a "node as Type cast" but a node:Type cast.

The node:Type is a source of many of our type system exceptions. IMO, we should get rid of it for the reasons mentioned in  #688.

[arimer]

@alexanderpann , @mgronover IMHO letting the TS fail with with a NodeCastException is more helpful, because it raises awareness that the overriden type is not compatible. It is more helpful than just "failing silently" and do not calculate any type.

[alexanderpann]

@arimer We probably have to check all those instances and check that we don't fail silently. Maybe some null checks or additional type system checks are necessary. For most cases, I would assume that we already have typesystem equations that enforce the correct type. Throwing fatal errors for cases where the user provides the wrong type, the editor is incomplete, an abstract concept is used, or an RuntimeErrorType is returned because of related errors is never an acceptable form of showing errors. All those cases have to be caught by the type system and shown in the editor by the type system, for example, type X is not a subtype of Y or the checks and calculations shouldn't be executed when the error happens earlier.

I really want to avoid any exceptions that are shown in the lower right corner. No user should read exception traces. Those notifications are for bugs only.

[arimer]

@mgronover in case we merge this, what do we need todo on the stading branch?