Semantic snippets: handle case with inline statement snippets before member access expression

[DoctorKrolic]

Previously inline statement snippets chacked, wherther they are part of a member access expression with parent being an expression statament. The second part of the check makes sure, that in cases like Invocation(validType.$$) the snippet isn't offered since we cannot insert a statement inside an invocation argument. That logic had ta flaw. It couldn't handle case like this:

validType.$$
Console.WriteLine();

Here syntractically we have the same thing as validType.$$Console.WriteLine();, therefore a snippet is executed in a hierarchy of expressions, thus by the previous rules is invalid there. But it is obvious, that this is just a state-of-the-world during typing and the snippet should be offered. Thus I changed how the core logic works. Instead of traversing a potentially complicated subtree I made a check, whether a position before the inline expression is suitable to insert statement into. This both guards us against Invocation(validType.$$), but also suggests snippet in the primary case we want to fix. However, I didn't want snippets to appear inside a line as you edit it, e.g. I don't think foreach snippet will be useful if you are inside enumerable.$$Select(..., in such case you probably want to add a method to the call chain or something similar. Therefore I made an additional line checks, so now inline statement snippet can only be the last "member access" on the line. Yes, we usually compute completions based only on previous tokens, but snippets stand out quite a bit, so I think that such approach to them is ok

[DoctorKrolic]

@akhera99 PTAL

[akhera99]

Looks good, thank you for the contribution!

[DoctorKrolic]

Can we merge this one please?