Tracing statistics: separate status view handlers from actual processing

Doing this makes debugging and performance optimization way easier.
Tracing statistics: improve code formatting in back-end
Tracing statistics: remove not used inputs and relation map
Tracing statistics: make all imports explicit

Using *-style imports puts a lot of things into the module's namespace,
potentially shadowing things from earlier imports. Avoiding them makes
the code more readable and robust, because you exactly know what is
imported. In theory, it also saves a tiny bit of memory and reduces
loading time. Additionally, I can use pyflakes to look over the code.
Tracing statistics: improve performance of user node count

Joining the treenode and the user table is costly. Therefore, this
commit decomposes this into doing the count/aggregation first and then
getting the names to the user IDs in a fast second query.

In my test data set with 6677982 tree nodes this improves the
performance of this query from 2.4s to 1.5s.

This commit is part of dealing with issue #625.
Tracing statistics: improve performance of review editor queries

Like with the node creation query, it is much faster if one gets the user
information separately. For the 6677982 tree node test set, the review stats
timing went down from 2.4s to 1.6s and from 950ms to 890ms.

To improve performance further, it might be sensible to omit the user name
query on the back-end and use the user information stored at the front-end to
replace the user IDs.

This commit is part of the work for issue #625.
Tracing statistics: bring node count API more in line with rest

Instead of using /stats one now can get the node count with
/stats-nodecount. The basic query itself is now done with raw SQL as
well. This, of course, doesn't bring any performance benefits, because
it is the very same as what the Django ORM created.

This is related to issue #625.
Tracing statistics: make URLs more REST like

This is only a cosmetic change. Instead of e.g. /stats-nodecount there
is now /stats/nodecount in use. This adds more consistency with the all
the other URLs.
Tracing statistics: simplify widget initialization

There is no dedicated view class needed for the statistics widget. A very simple
template is returned. Therefore, this commit employs Django's built-in
TemplateView directly. The URL to retrieve this widget has been simplified as
well: instead of /statisticswidget is now reachable with /stats.
Tracing statistics: split page refresh in sub methods

This improves in my eyes the readability of the code.
Tracing statistics: ensure statistics are loaded after layout

This commit moves the request of the actual statistics in the callback of the
layout loading, because we can't know how long it takes for the layout to be
available.
Tracing statistics: make user history date range adjustable

This commit adds two new text boxes two specify a start and an end day
to show the user history for. It can be adjusted with the help of a new
"refresh" button next to it. The start defaults to ten days ago.

This is part of the work for issue #625
Added alternative catmaid_frontend + example
Merge pull request #628 from schlegelp/catmaid-python-frontend

Added alternative catmaid_frontend + example
Fix some typos in Celery related documentation

Two of these typos were in the Django configuration for Celery, so it is
important to have this correct.

Thanks Albert Cardona for bringing those typos to my attention.
More informative comment on urls.py for catmaid application.
Fix typo in ConnectorExporter comment.
The ConnectorExporter.create_path must create the path with a Connector ID,
not with a TreenodeConnector ID.

Additionally, the ConnectorExporter.create_path function takes
a TreenodeConnector as argument rather than a Connector. The name
of the argument must reflect that fact.
Data views: add tag, project and stack indices to template context

These indices allow a much faster access to tag, project and stack data. All the
required logic can be done based on them which would reduce the number of data
base requests tremendously--at least if there are many projects, tags or stacks.
Their creation doesn't take much time.
Add basic Django template filters for working with sets, lists and dicts