Adds JSHint to the build step + code clean up

This is a quick show of what #116 might look like. I have no idea what I'm doing in Make, so that stuff was basically just made up. And it doesn't work. :worried:

I just ran JSHint from the command line to make the code changes. It looked like there were a few places where there was placeholder code, so maybe you'd prefer to just relax the linting on those files. But there are some legitimately useful cleanups in here as well, I think.

The .jshintrc file can be telling about the general health of the library, too. For instance, the maximum function depth is 6, and there are a handful of methods with [cyclomatic complexity](http://en.wikipedia.org/wiki/Cyclomatic_complexity) > 6. That might sound like a bunch of gibberish, but it is suggestive that the code might be more difficult to test than it needs to be. These possibly negative attributes could be resolved by splitting up some of the larger methods in this library into smaller ones. An example of a pretty big one is this [120-liner](https://github.com/Khan/KaTeX/blob/master/src/buildTree.js#L248-L367).

Speaking of that method, there are a handful of outstanding JSHint problems with it that I didn't get around to solving for this initial PR. The list can be seen [over in this gist](https://gist.github.com/jmeas/550535b1e637e388b802).
No, that's not how `.PHONY` works. `.PHONY` is just a special rule that says "things listed here won't actually create the file they are named after" (this generally means that they're commands you want to run, not things that build files). So the `lint` rule won't create a `lint` file, so it should be in `.PHONY`. But it's not transitive, so something in `.PHONY` doesn't only have `.PHONY` dependencies. Make sense? (you can read [this SO question](http://stackoverflow.com/questions/2145590/what-is-the-purpose-of-phony-in-a-makefile) for some more info.