Trailing closure content assist pref can produce strange replacement

[eric-milles]

Assuming "Place trailing closure arguments after closing parenthesis" is checked (current default) and other content assist preferences are default as well, and given:

contribute(currentType()) {
  method name: 'foo', params: [bar: String, block: Closure]
}

fo|

Content assist at | with "Use closure literals for closure arguments" unchecked gives foo(bar) block -- replace "block" with literal "{ }" and selection/caret goes inside literal instead of covering it.

[].co|

Content assist at | and select "collect(Closure transform)" proposal gives [].collect transform -- replace "block" with literal "{ }" and selection/caret goes inside literal instead of covering it.

Placing the expression outside the method call parens means a closure literal is required for correct syntax. If a new-to-Groovy user cancels out of linked mode, the code will be invalid. Providing a literal expression will result in proper syntax immediately.

Part 2:
If { is pressed to trigger the proposal, foo(bar) { it } is inserted with selection tab groups for "bar" and "it" and after closing brace. The usefulness of "it" is questionable and it would be better served if tab groups were set for "bar" and inside the closure, with the exit position being inside the closure as well. That is replacement would be foo(bar) { | } with | indicating both second tab group and linked mode exit position (where caret goes after pressing enter or escape). This matches the proposed end state for the two examples above.

This is a follow up from #603

[ybayk]

@eric-milles, please assign this issue as well as #626 to me