Updated junit bundle names in manifest files.

In the upgrade to Eclipse 4.x, the junit bundle names changed from 'org.junit4' to 'org.junit'.
Merge pull request #161 from jhaberstro/manifests-junit-bundle-names

Updated junit bundle names in manifest files.
Fixed weird behaviour in new template editor.

What was essentially happening is that there were text regions that had overlapping bounds. They had overlapping bounds because (a) I was forgetting to change both the region's "length" and the region's "textLength" and (b) AttributeNameRegion (from wst) implemented its adjustTextLength method to always increment its text length by 1 (instead of respecting the passed in parameter). The fix was to reimplement (correctly) AttributeNameRegion in a subclass of AttributeNameRegion (a near full reimplementation had to be made because the fields of the AttributeNameRegion are private, rather than protected..).

Fixs #164
Merge pull request #165 from jhaberstro/template-editor-weird-behaviour-164

Fixed weird behaviour in new template editor.
Introducing the new template parser.

This is squashed commit of many changes. Here is a list of major changes introduced:

1. Added the ability to include or exclude a trailing '.' on chained method calls.
2. TemplateRegionParser optimisations.
3. ScalaTemplateParser optimisations.
    - This mainly consisted of rewriting mixed, matchExpression and caseExpression to never back track by merging matchExpression with safeExpression and expression, and having caseExpression accept just whitespace instead of waiting for plain to later eat it.
4. Better template parse error reporting.
5. Added error report for caseExpression and fixed bad source position of forExpression.
6. Fixed completion bug that occurred when the text replacement region was zero-length (i.e., after a '.')
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
Merge pull request #169 from jhaberstro/new-template-parser

New (faster!) template parser