Add static code analysis tools, refs item:557

I came across the article [Eliminating Code Smell With Grunt][1] and particularly liked the [enforcement section][2].

This adds a new grunt task `grunt checkstyle`, which runs the codebase through a number of static code analysis tools (JSHint, ESLint, jscs, jsbeautify).

We've started documenting our [coding conventions][3], but rarely is it enforced. As the codebase grows, we need to be wary of code smells (a recent one being overloading of returned values). These tools can help prevent such smells and enforce consistency throughout, particularly helpful for new developers reviewing the code.

JSHint is the current de facto Javascript linting tool, but it's not extensible. I propose the introduction of ESLint and jscs.

ESLint is akin to JSHint, but pluggable: every rule is well-defined, it's easy to add new ones and it covers a lot of useful areas such as [space-after-keywords][4] that JSHint doesn't. It focusses on linting and will
soon be a JSHint replacement when feature parity is reached.

jscs focusses on code style and therefore has more control over formatting and whitespace rules.

I've added a starting `.eslintrc` and `.jscsrc` based on our existing conventions and [popular conventions][5] in the OSS community. However, these are very much up for refinement between the team.

To enforce these conventions, it's as simple as adding the `checkstyle` task to Travis, which will fail the build if there are deviations. Developers are also encouraged to use IDE plugins or even a Git pre-commit hook as a first pass locally.

I've left this out for now as the rules need discussion and there's a long way to go before everything is lint-free (try running `grunt checkstyle` to see for yourself).

It's a little draconian, but as the project grows, it's important to maintain consistency, to aid readability and kill smells quickly.

[1]: https://gist.github.com/gvn/7536832
[2]: https://gist.github.com/gvn/7536832#enforcement
[3]: https://github.com/eHealthAfrica/LMIS-Chrome/wiki/Coding-Conventions
[4]: http://eslint.org/docs/rules/space-after-keywords.html
[5]: http://sideeffect.kr/popularconvention#javascript