checker: apply stricter type checks to function args and return types

[UweKrueger]

This PR makes type checks more consistent by introducing the same type checks for function arguments and function return types that have been introduced for other cases in PR #4971.

[UweKrueger]

Build of vid and ui are temporarily disabled until PR #74 and PR #147 are merged there.

[medvednikov]

@UweKrueger I think we should make gg use f64 by default instead of all the casts.

[UweKrueger]

@medvednikov: I've changed the interface of gg to use f64 and this really simplifies a lot. I haven't changed gl* because the called C routines use float. So there are still conversions to f32 but the are encapsulated in gg.
I've retracted PR #147 and re-enabled the ui build. For vid there are still some conversions in PR #74 that need to be merged there.

[medvednikov]

@UweKrueger there was a big discussion on Discord (#gamedev), and it was decided that it's best to use f32 in gg, but keep f64 by default for the literals, like in C/C++, C#, Java etc.

I was wrong, sorry :)

[medvednikov]

I'll be introducing f suffix for shorter notation 100.5f is f32, 100.5 is f64.

[UweKrueger]

Actually, I already felt uneasy when I implemented that, since f32 is used everywhere in gl and it seems that GPU performance differs significantly between f32 and f64.

I've reverted the relevant commit.

[UweKrueger]

100.5f is f32, 100.5 is f64.

Agreed, but 100.5 could remain any_float (since we have that now) with default f64, so
a := 2.3f // -> f32
b := 12.7 // -> f64
c := a + 5.6 // -> f32

[medvednikov]

Yes, exactly :)

Thanks

[medvednikov]

error: cannot use type `int` as type `f32`

@UweKrueger I think this should be allowed, since f32 > int

[UweKrueger]

@medvednikov yes, even though there might be a loss in precision, this kind of automatic promotion makes life easier, especially when using f32 arithmetic.
I've created PR #5174 that allows this promotion (and similar ones) again.