Add external mapShim/debug modules

[rbuckton]

This moves sys.require from tsserver to compiler so that NodeJS modules can be loaded via sys if available. This enables us to move the Map shim out of tsc.js, since it will be most likely run in a NodeJS environment that already supports it and will cut down on unused code in the command-line compiler. The Map shim script is designed such that it can be bundled with typescriptServices.js/typescript.js, allowing it to continue to run in environments that do not support module loading and may not have a native Map implementation.

This also enables us to dynamically load extended debugging tools when debugging the compiler without also adding code to the compiler that would be unused in most situations.

As part of this change I also moved all of the general path-manipulation logic out of utilities.ts and into a new path.ts file. This was motivated by the need to leverage some of the path manipulation logic before we evaluate scanner.ts/parser.ts which unconditionally create Map instances (and therefore would depend on sys.require and path manipulation already being present).

[rbuckton]

cc: @ahejlsberg as this adds the additional control-flow debug info via an on-demand-loaded external module.

[weswigham]

The Map shim is essentially just for old ie runtimes at this point. Polyfilling it lazily using require defeats the point, since that runtime doesn't have require?

[rbuckton]

True, but IE will generally be running typescriptServices.js/typescript.js, which bundles mapShim. This is also the implementation I'm using to shim Promise in the plugin prototype branch.

[rbuckton]

Since tsc.js will never require() the map shim, and since typescriptServices will always bundle it, I'll remove the logic to try to require() it if the ts.createMapShim function can't be found and have it throw instead.

[rbuckton]

I lament that ts.Map<T> was defined with a single type argument and was made public. It should have been ts.Map<K, V> (or ts.Map<K extends string, V>) so that we could possibly move to using a full Map shim that supported number/boolean/object/etc. at a later date without having to use something like ts.ESMap<K, V>.

Speaking of which, I have a branch where I've improved the Map shim to allow for arbitrary keys (and has ideally the same storage size for string-only keyed maps), as well as added a Set shim. Its fairly efficient for keys that are string/number/boolean/null/undefined, but uses a linked-list for object keys. They obviously wouldn't be efficient for objects, but would in effect just be a safety net for running typescriptServices.js in IE.

[rbuckton]

@weswigham any other thoughts/comments?
@RyanCavanaugh any concerns with changing tsc.js to no longer ship with a polyfill for Map?

[rbuckton]

@weswigham: Any other feedback or concerns on this?