Experiment with JavaScriptLifter inlining heuristic that tries to avoid additional brackets

Currently, the JavaScriptLifter is fairly "greedy" about its inlining decisions and mostly inlines expressions whenever possible:

1. There is a single use of the produced value (or if the expression is pure)
2. There is no other effectful operation between the operation that produced the expression and the operation using the value (otherwise, inlining would change the semantics of the program)

However, this can lead to somewhat hard to read code. For example things such as

print((new X).a);

or

("1234").foobar();

Currently we manually try to avoid some of these patterns, for example by forcing the constructor value to be an identifier for a construct call. However it could be the case that a simple heuristic would also work here instead of a manual "denylist": we avoid inlining if we would require additional brackets (such as in the examples above). Maybe for arithmetic operations we allow adding brackets, but forbid them for other expressions and instead force the creation of a new variable. Ideally, we would design the new algorithm in a way that also allows us to remove the somewhat awkward logic for expression un-inlining.

I think it would be worth experimenting with such a heuristic to see how the generated samples look like.

Read Sources/Fuzzilli/Lifting/JavaScriptLifter.swift, including the constructor inlining logic near line 774 and expression un-inlining logic near line 1694. Experiment with a heuristic that avoids inlining when additional brackets would be needed, while considering arithmetic expressions separately. Done means generated samples are easier to read and the awkward un-inlining logic can potentially be removed.