Commented/better documented the new template parser & code tidiness.

Removed extraneous reverse and lifted an if statement outside of a loop/map in the CompletionComputerComputer implemention.
Removed remnant variable from when I was switching between parsers while debugging the new parser.
Template parsing and compiling is now thread-safe.

Previously, ScalaTemplateParser was not thread safe because of the globally accessible inclusive-dot flag. This has been solved by making the flag a parameter of ScalaTemplateParser.parse method. However, because ScalaTemplateParser is hidden behind (in some instances) the ScalaTemplateCompiler object which in-turn is hidden behind TemplateCompilationUnit, some refactoring of ScalaTemplateCompiler and TemplateCompilationUnit was needed. Now, TemplateCompilationUnits are created with the "inclusive-dot flag" as a constructor val arg, meaning that once a TemplateCompilationUnit is created, it can't change how it parses trailing dots in chained method expressions.

ScalaTemplateCompiler was also unsafe for several reasons:
(1) A single ScalaTemplateParser was being shared among each compilation request (a call to compileVirtual). ScalaTemplateParser is rather lightweight, so this has been fixed by simply creating a new instance each time a compilation is performed.
(2) How the inclusive dot is parsed affects the actual contents of the resulting virtual file (meaning, there are two possible files, the non-inclusive dot version, and the inclusive dot version). They were both being compiled to the same virtual file. Now, they aren't.
(3) There was an internal instance of the scala compiler, which itself isn't thread-safe. All of the related state to this scala compiler instance has been made private, and any indirect public access to it has been synchronised.
The "inclusive dot" is now a class val param of ScalaTemplateParser

It was previously a method parameter to ScalaTemplateParser.parse