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
Update of bracket auto edit strategy

The old behavior was inconsistent, thus it is changed to follow these
two rules:

1. An opening brace is always closed except when it is inserted directly
   before non white space:

     xs map ^(_+1) ==> xs map {^(_+1)

2. Furthermore, an opening brace is not closed if there are unmatched
   closing braces after the caret position:

     xs map {^}} ==> xs map {{^}}
Merge pull request #267 from sschaef/issue/bracket-auto-edit-strategy

Issue/bracket auto edit strategy
Correct syntax highlighting for while-keyword

While syntax highlighting correctly recognizes the while-keyword as a
keyword, semantic highlighting treats it as a method. Because semantic
highlighting is activated after its syntax counterpart, it overwrites
the previous detected colors.

The new behavior omits the method symbol detected by semantic
highlighting for while-keywords.

Fix #1000984