Drawbacks:
* Only covers cases where the invocation is nested within an executable statement
* Performs abysmally due to creating a whole speculative semantic model for the vast majority of invocations, and additionally using GetOperation which is quite slow in general

At some point amongst all the code that runs there is presumably a crucial function which has the rules for binding a name-type syntax into an invocation.
Ideally we'd find a way to call just that function here on invocationExpression.Expression

Therefore we can't know it's safe to remove parentheses since it could be a delegate

This is to allow "TestInsertCallIfNecessary3()" to continue to pass.
Note that the test result isn't fully simplified since it says:
Call (Sub() Exit Sub)
instead of
Call Sub() Exit Sub
This is outside the scope of this PR

There is no parameterless Console.Write hence it doesn't resolve, and Program doesn't exist in the context at all
Don't think it's worth considering CandidateSymbols since they won't always be correct

Expanding and reducing stuff that doesn't compile sounds generally risky. In a future PR perhaps the expander shouldn't add the parentheses if it can't resolve the symbol.

If it wasn't invokable it wouldn't be valid at this point

This reverts commit 3787058.