Don't check the unfinished expression before dot as the whole expression

[auduchinok]

A test PR to check what breaks with this change.

Consider an unfinished expression with a dot at the end: x.. In many cases the dot would be ignored and only x expression would be checked. It has bad consequences where the type of x is unified with the type that is expected in the context, despite it's an inner expression in another unfinished one:

let f x =
    if true then
        x. // `x` is inferred to have type `unit`, which is not expected

That unexpected unit type breaks completion for cases where x should infer to have some other type, like string here:

let g (s: string) = ()

let f1 x =
    if true then
        // user wants to type `Length`,
        // but there's no completion, since `x` is mistakenly considered `unit`
        x. 

    // an error about `unit` not being compatible with `string`
    g x

// the same issues:
let f2 x =
    x. // trying to use `x` members from code completion
    g x

With this change both cases work as expected (i.e. x doesn't have any constraints in the first case and code completion suggests string members in the second one).

Another case is applying an argument:

let g (i: int) = ()
let h (s: string) = ()

let f x =
    g x. // `x` is inferred to `int` instead of `string`
    h x // an error

[auduchinok]

I've removed a few other related cases that prevented a good type checker recovery.

Before, the right side is ignored:

After, the right side is type checked with the unknown type of the missing expression after dot:

[auduchinok]

Please merge #14739 first, and I'll update the tests here afterwards.

[psfinaki]

@auduchinok there you go :)

[auduchinok]

@psfinaki Thanks!

I've updated parser tests for unfinished expressions (A., A.B.) and added more tests for various incomplete record field cases (the parsing got broken there in the initial implementation, and only Code Completion tests caught it).

It's ready now.