fix: Remove parentheses around targeted expr in binary or unary op

[Egor18]

fix #3021
I think there is no need to wrap any CtTargetedExpression in parentheses when it is used in binary / unary operations (precedence is higher anyway).

[tdurieux]

I think it can be required when the element is casted.

[Egor18]

The case with casts is still handled:

spoon/src/main/java/spoon/reflect/visitor/DefaultJavaPrettyPrinter.java

Lines 357 to 360 in fb04264

	private boolean shouldSetBracket(CtExpression<?> e) {
	if (!e.getTypeCasts().isEmpty()) {
	return true;
	}

I added a test just in case.

[monperrus]

LGTM.

we may miss a special case here, but if there is no test, we don't know. We will catch it with jenkins and upcoming #2724

[Egor18]

Well, I looked through all of the possible CtTargetedExpressions:
CtAnnotationFieldAccess<T>, CtArrayAccess<T,E>, CtArrayRead<T>, CtArrayWrite<T>, CtConstructorCall<T>, CtExecutableReferenceExpression<T,E>, CtFieldAccess<T>, CtFieldRead<T>, CtFieldWrite<T>, CtInvocation<T>, CtNewClass<T>, CtSuperAccess<T>, CtThisAccess<T>
and all possible binary and unary operators, and I don't see any counterexamples.

BTW, the similar fix is possible for #2330.

[nharrand]

LGTM too.