Faulty Content Assist Within Blocks

## Current Behavior

Under specific conditions, content assist provides proposals as expected in the context. Consider the following code:
```java
public boolean doIt() {
while (true) {
Integer i = 0;
i.
((Object)i).getClass();
}
}
```

Opening auto-completion proposal after the `i.` does not provide content assist for `i` but for its context:


The conditions for this problems I found so far are as follows:
* Be inside a block, such as a condition block or a loop block
* The line after the incomplete line, in which content assist shall be used, starts with a cast

## Expected Behavior

The content assist should provide the methods of `i` as proposals, same as when one of the conditions above is not fulfilled. For example:
```java
public boolean doIt() {
Integer i = 0;
i.
((Object)i).getClass();
}
```
shows:


## Further Investigations:

- The vaariable inside a while or if block is parsed as an AST Node of type CompletionOnMessageSendName while the other variable which is not inside any block is computed as a CompletionOnQualifiedNameReference.
- The difference starts inside the parser (Parser.java) which uses a method consumeRule(act) which creates CompletionOnMessageSendName because of the value of act being 607 while the other has a value of 619.
- these 2 codes in the switch/case of consumeRule method produce 2 different kinds of nodes.
- Later, these nodes throw a CompletionNodeFound exception wrapping their scope and the astNode in the exception in CompletionEngine.java, where the information of the scope and the node type is used to generate codeComplete Proposals.

- In the case 607, the changed the method consumeMethodInvocationName to consumePostfixExpression, which is also used for 619.
- You get the right recommendations for the variable in the block after this change. However, the change of the method in the case 607 makes the other part of the code behave differently.
- Seems like the TypeBinding (SingleVariableBinding) is not present in the ASTNode, which is need for the propsals. I tried adding binding manually but there's some cast checks which doesn't allow this kind of binding for the object of type CompletionOnMessageSendName.

**Note**
- If we don't have the line ((Object) i).getClass(); following the line "i.", it gives the right proposals. On debugging, I found out that without the following line, the parse parses i.((Object) i) as CompletionOnQualifiedNameReference node.

Conclusion:
Hence we can conclude that there is something wrong with the parser and it should not be parsing it as a CompletionOnMessageSendName but CompletionOnQualifiedNameReference.

Another Observation is that when we have a type cast in the following statement followed by a method call, this issue is specific to that case. On printing the scanner in 2 cases, it looks like this:
1. When we have a following statement which satisfies the condition mentioned above:
```
public boolean doItFaulty() {
while (true) {
Integer k = 0;
k.
((Object)k)
===============================
Starts here -->.<-- Ends here
===============================
getClass();
}
```

2. When there's no satatement as mentioned:
```
public boolean doItFaulty() {
while (true) {
Integer k = 0;
k.
// ((Object)k).getClass();

===============================
Starts here -->}<-- Ends here
===============================
```

In other words, the parser parses for the following statements:
```
k.
((Integer)k).getClass();
```

as:

```
.getClass()
```

Reproduce the example in the issue with `i.` followed by `((Object)i).getClass()` inside a block. Start in `Parser.java` at `consumeRule`, comparing cases 607 and 619 and the `consumeMethodInvocationName`/`consumePostfixExpression` paths; then inspect `CompletionEngine.java` and `CompletionNodeFound` handling. Done means content assist proposes methods of `i` in the reported case without breaking the other case.

Written by the indexing model from the issue text.