Caused by the fact that IE8 doesn't allow the reserved keyword 'enum' to
be used inside a member expression, like so:

    someObj.enum

So I had to rewrite it like so:

    someObj["enum"]

IE9 and other browsers didn't have a problem with that.

Enhance Util::Json.parse to accept an options parameter which Esprima
class needs to pass.  Now everything accesses the JSON gem through
JsDuck::Util::Json wrapper.

Results in much simpler code without all the self.method_name uses.

Use it to abstract away the singleton logic in Logger.

This way splitting the assets into subgroups will help to reduce the
amount of information shown in ThumbList display.

Nested groups can be defined as follows:

    [{
        "title": "Main group",
        "items": [
            {"title: "subgroup",
             "items: [ ... ]}
        ]
    }]

In UI the tree will then show subfolders for the nested asset groups.
But the ThumbList display will still show all the assets in old way,
and the assets in subgroups will be expanded so they will appear as if
they were listed directly inside the top level group.

I guess in some way this beats the whole point of having the subgroups -
as all the assets still show up on the main page as if there were no
subgroups at all.  On the other hand we now technically have support for
subgroups, but I feel that's not really what these users were after when
they asked for nested grouping.

Additionally eliminated :dup_asset warning.  It didn't fit nicely to the
new way of iterating over assets, and I think it wasn't such a useful
warning anyway.

The class was for long no more in use, but the file was left undeleted.

A bit less stuff in the main JsDuck namespace.

Included a mini-library 'regexp-quote' which provides just one but
useful function.

Esprima now rejects those pieces of code as invalid JavaScript.

The new esprima no more considers newlines as part of line comments.

Let Esprima have its window object - otherwise it'll just crash.

We could simply query the forum database every time we need the e-mail
address, but I think it's better to keep interaction with forum database
to a minimum.  Besides, changing the e-mail address happens very rarely
and at least we now have this case covered.

This way we can take advantage of automatic updating of the created_at
fields and don't need to insert new Date() into all of those columns.

The old comments backend worked just fine with one shared connection, so
we shouldn't get quickly into troubles with this approach.

Previously the number of open connections just kept growing and growing
because they never got closed.  At least this problem is now gone -
there's just one open connection which we never close.

- Actaul application files go to comments/lib/
- Jasmine tests go to comments/spec/

The e-mail sender we use is configurable in ./config.js.