In an effort of ensuring consistent code style in test files as with
the "production" source code, we should run eslint as part of the
`$ npm test` script as well.

Most of the related fixes was done by `eslint` using the `--fix` argument.

Only special configuration tweaks for tests compared to the other
source code, is to allow functions declaration without names. The
rationale for allowing that in tests, is that the important reason we
have them in the source code (proper stacktraces) aren't as important
in test files.

- Cleaner separation of responsibilities in the code between
  scanning, parsing, compiling, and rendering functions.
- Much faster

This commit is a complete rewrite of the core mustache.js file with two
main goals: 1) a major performance boost and 2) better compliance with
the mustache spec.

In order to improve performance templates are pre-compiled to JavaScript
functions. These compiled functions take a view, a partials object, and
an optional callback as arguments. They are cached to prevent
unnecessary re-compilation of an already compiled template. Both of
these enhancements facilitate a generous boost in performance.

A few other notes:

- The mustache.js file is now both browser and CommonJS ready without
  any modification.
- The API exposes two main methods: Mustache.compile and
  Mustache.render. The former is used to generate a function for a given
  template, while the latter is a higher-level function that is used to
  compile and render a template in one shot. Mustache.to_html is still
  available for backwards compatibility.
- The concept of pragmas is removed to conform more closely to the
  original mustache spec. The dot symbol still works to reference the
  current item in an array.
- The parser is much more strict about whitespace than it was before. The
  rule is simple: if a line contains only a non-variable tag (i.e. not
  {{tag}} or {{{tag}}}) and whitespace, that line is ignored in the
  output. Users may use the "space" option when compiling templates to
  preserve every whitespace character in the original template.
- The parser is able to provide detailed information about where errors
  occur when parsing and rendering templates, including the line number
  and surrounding code context.