Improve error baseline reporting

Conflicts:
	tests/baselines/reference/accessorWithInitializer.errors.txt
	tests/baselines/reference/accessorWithRestParam.errors.txt
	tests/baselines/reference/duplicateNumericIndexers.errors.txt
	tests/baselines/reference/errorSuperCalls.errors.txt
	tests/baselines/reference/functionTypeArgumentArrayAssignment.errors.txt
	tests/baselines/reference/incrementAndDecrement.errors.txt
	tests/baselines/reference/inheritedConstructorWithRestParams.errors.txt
	tests/baselines/reference/inheritedConstructorWithRestParams2.errors.txt
	tests/baselines/reference/optionalSetterParam.errors.txt
	tests/baselines/reference/overloadresolutionWithConstraintCheckingDeferred.errors.txt
	tests/baselines/reference/superCallsInConstructor.errors.txt
	tests/baselines/reference/superWithTypeArgument.errors.txt
	tests/baselines/reference/superWithTypeArgument2.errors.txt
	tests/baselines/reference/superWithTypeArgument3.errors.txt
Use tsc.js-style error messages in error baselines

Conflicts:
	tests/baselines/reference/accessorWithInitializer.errors.txt
	tests/baselines/reference/accessorWithRestParam.errors.txt
	tests/baselines/reference/inheritedConstructorWithRestParams.errors.txt
	tests/baselines/reference/inheritedConstructorWithRestParams2.errors.txt
Fix bad rebaselining from cross-branch fixes
Too aggressive in removing parentheses when casting
We have been omitting parenthesis of cast expressions across the board. this results in better looking JS code, but could
result in change in the semantics of the generated code, or even broke code as the parentheses removal changes precedence.
Consider these examples:
     (<any>new A).foo  => should emit (new A).foo and not new A.foo
     (<any>function(){})() => should emit (function(){})() and not function() {} ()
     new(<any>a()) => should emit new (a()) and not new a()
We have an option of always emitting the parentheses, but that leads to ugly JS code. Instead, we can optimize for the
common case, e.g. (<any>A), or (<any> A.B) to remove teh parentheses from, and keep it for other expressions.  In this
change I have picked a set of nodes, that are common in cast expressions, that can be deemed "safe" to remove cast
expression parentheses around. "Safe" expressions should have high enough precedence that, removing the parentheses
should not affect their order of evaluation, namely literals, dotted names and index access.
Update LKG
Change type baselines and emit baselines to include .ts sources like the error baselines for easier comparison
Merge branch 'release-1.0.1' into develop#
Update LKG
Add a richer rename api.
Fix encoding issues.
Merge branch 'develop' into languageService-v2