Allow selection of user from users list and then filter the comments
list to show only comments of that user.

The selection of user is not saved into settings, but is stored until
the next page refresh.

With the sole responsibility of providing a way to perform
queries to the comments backend.

Let links be blue as they should be.
Hide the member type info from link - it's not that important.

Now the tab panel of users list makes sense.

The page is now also visible to normal users, with the only difference
that hideRead checkbox is only shown for moderators.

The page is divided into two sections: comments & users.

The comments section has two tabs which determine how the comments are
sorted (instead of a checkbox determining it).

The users section has a list of all users sorted by votes.

Store the session cookie also when user is not logged in - just to keep
his session ID and not create a new session for each and every request.

Additionally use Ext.JSON instead of JSON.

Previously the receiver of comment was used in place of the actual
author.

The latest 3.0.0rc4 release broke JSONP requests handling.
Additionally I'm getting some strange 404 errors.

This was to just try out some queries.
Most of them have now been implemented.

Instead of dropping and recreating the database we now drop all the
tables and then recreate them.  This is because in our staging server I
currently have just one database available and I can't drop and recreate
it to run tests in it.

Additionally eliminated the update_votes.sql script - the triggers
themselves take care of votes being calculated.

This way the stdout can be directed to file and the file will only
contain SQL that can be fed into MySQL.

Also added error message when connecting to mongodb fails.

Fixed hard-coded offset on overview panel scroll into view.

As a first step in expanding FunctionAst to do full detection of
various return types, not just whether we're returning this or
something else.

We're now able to determine if the execution can flow through a control
structure or will the control structure always result in a return statement.

Forgot to update the @version in Options class and already pushed the
gem into rubygems.org.  So no other option than to release a next minor
release.

A regression introduced by refactoring the code from JsDuck::Class to
JsDuck::Lint.

Full match variable in ruby is $& not $0.

No need for it to be inside App.  The configuring of Logger already
happens inside Options, so lets have the others there too.

It was implemented long-long time ago and I doubt it's of much use.
Even if somebody uses it, the same information can be retrieved from
--export=full.

Now the App class really can be called simple.

Finally the App class is now relatively simple.

The class was still using the old JsonDuck instead of Util::Json.

Split the huge method into lots of smaller routines.

Move all the messy parsing logic away from already overcomplicated App
class.  Now the App is left with pretty much just one method that
represents the flow of the entire app.  It's still too complicated
though.

This new class encapsulates the formatting of all classes.

Also, while formatting, we now create a new class_formatter for each
class that we process.  That's because otherwise the list of images
detected in one class will be added to the images detected from the next
one, and so on and on...  This wasn't really a problem because we
stripped away the duplicate images anyway, but it wasn't really the
right way to do it.

- Constructor now takes just opts and relations is passed in separately
  through accessor.
- Remove old leftover: @images variable.