First pass at fixing TypeScript definition parser.

I'm attempting to create a module that helps with the creation and management of Tern definition file from TypeScript definition files. On the surface this seems pretty straightforward, by creating a simple interface between [tsd](https://github.com/DefinitelyTyped/tsd) and Tern's own `from_ts` parser.

However, the `from_ts` parser is buggy right now and hasn't been updated in awhile. It's also untested as far I can see. Additionally, it comes in the bin w/ `tern` but cannot be used unless dev dependencies are installed (since it does the vm "kludge" to gain access to TypeScript).

I have a few issues that I'd like to bring up, relating to this and to Tern in general:

1. The Tern codebase is not something that is very approachable by someone wanting to hack on it. Sure, some of this is sort of the nature of the beast, considering what it's doing (and the criticality of speed and call-stack limitations), but considering this is the author of Eloquent JavaScript (which I recommend to anyone looking to learn JS :+1: ), I'm pretty sure it could be better.

    From the perspective of a highly experienced JavaScript developer who isn't a mad genius, I can understand all of the code, but wish for a bit more readability and additional abstractions. Perhaps some documentation where abstractions are not affordable.

    So the sensitive question would be, are you amenable to something of this nature? What I'm talking about is something like changing:

    ```js
    if (ch == 10) break;
    ```
    to
    ```js
    var NEWLINE_CHARCODE = 10;
    // ....
    if (ch == NEWLINE_CHARCODE) break;
    ```
2. If `from_ts` isn't like a neglected bastard child, I don't know what is. I'm putting forth a suggestion to separate it out from Tern completely. If you're amenable, I can help by getting it tested and focus on getting it to more deeply extract information from TS.

    It's certainly got potential in my mind, due to the large collection of TSD files out there. People using Tern are already required to deal with `.tern-(project|config)` files, and `tsd` uses JSON to manage install definitions.

    Creating a simple CLI that facilitates setting up Tern and accessing definitions seems both simple and highly useful to me. I can see many additional possibilities as well, but this seems like the lowest hanging fruit.

3. No one knows about Tern, and yet it's so spectacular! I would love to see that change. Everyone who I show its capabilities to are immediately saying "I want that". In order to get Tern helping more people, it has to be:
    - Easy to setup
    - Easier to hack on
    - Documented better (e.g., the type defs structure is only cursorily explained)

Anyways, this PR specifically is summarized by the commit message. It's a massive improvement and I can provide examples if desired.