Revisit fix for Bug 576778 - it causes https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4216

The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=576778 changed `org.eclipse.jdt.internal.core.SelectionRequestor.acceptLocalVariable(LocalVariableBinding, ICompilationUnit)` from being:

```
if (local.type == null || local.type.isTypeNameVar(binding.declaringScope)) {
if (local.initialization instanceof CastExpression) {
typeSig = Util.typeSignature(((CastExpression) local.initialization).type);
} else {
typeSig = Signature.createTypeSignature(binding.type.signableName(), true);
}
} else {
typeSig = Util.typeSignature(local.type);
}
```

to

```
if (local.type == null || (local.type.isTypeNameVar(binding.declaringScope) && !binding.type.isAnonymousType())) {
if (local.initialization instanceof CastExpression) {
typeSig = Util.typeSignature(((CastExpression) local.initialization).type);
} else {
typeSig = Signature.createTypeSignature(binding.type.signableName(), true);
}
} else {
typeSig = Util.typeSignature(local.type);
}
```

I think this just circumvents the IAE without addressing the problem. See that in the case where a var typed local is initialized to an anonymous type, we would compute the type signature to be `Qvar;` - that doesn't quite sound right.