Fix #1001309

Because it turned out that the new behavior led to some problems it must
explicitly activated by turning off a new option, located in:

  Preferences -> Scala -> Editor

If the option is disabled, a brace isn't automatically closed if it is
located before some other source code in the same line. In the following
examples the caret is denoted by a ^ sign:

     `List(1) map^ (_+1)`
  => `List(1) map{^ (_+1)`

The former is transformed to the latter because the opening brace
doesn't occur at the end of the line. If a line contains only trailing
white spaces after the caret, this behavior is not applied:

     `List(1) map ^  `
  => `List(1) map {^}  `

It turned out that this behavior is annoying when an opening brace is
placed between an already existing pair of braces:

     `List(List(1)) map { _ map ^ }`
  => `List(List(1)) map { _ map {^} }`

Here, a closing brace is always inserted even though the option in the
preferences is disabled and the opening brace is not the last non white
space sign in the line. There is one situation left now where the
behavior can be tricky:

     `List(List(1)) map { _ map^ (_+1) }`
  => `List(List(1)) map { _ map{^} (_+1) }`

Actually, the caret is positioned before the argument of the function.
But it also occurs between a pair of braces, hence there is conflicting
behavior. Since it was not possible to exactly determine which behavior
should be chosen without doing a full (and slow) parsing of the source
code, the behavior inserting a closing bracket is chosen (as shown in
the example).
Another reason to choose this behavior is that the current indentation
engine also can not handle this "inline bracket case" - by hitting enter
it inserts a closing brace after the whole content, placed after the
caret, and not after the closing parentheses.
Refactoring of BracketAutoEditStrategy