Key bugs using a 32-bit signed int calculated using Java's fast String.hashCode

Code was taken from a response on StackOverflow:
http://stackoverflow.com/questions/7616461/generate-a-hash-from-string-in-javascript-jquery

This cut indexing time by 50% and index size by 20%.
Nothing is free though, and insert time is increased by 25%.

Inserting 1000 documents is till 6x faster than indexing them.
Several changes around views to reduce their weight

TL;DR This reduces both the number of views, reducing size
on disk and view server processing time, and in some cases
the number of trips to the view server.

This is a bit of a novel because it is a squash of three
well researched, but minor, commits.

Remove reduce functions which only returned null

In the description of Lookup Views on the wiki, they specifically mention that
null is an appropriate emit value for a view that will only be used for lookup.
I believe that having a reduce function defined for such a view will require
roundtrips to the view server, but won't accomplish any actual work. On the
other hand, not having a function will automatically default the view to
ignore the reduce function, at least for query side (but hopefully for
generation as well) as described in the query options section.

http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views#Lookup_Views
http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Use built-in _sum function where appropriate

This should eliminate trips to the view server by doing summation in the
erlang process. Documentation from couchapp (erica's predecessor) describes
the simple file with '_sum' as the correct way to do this for a couchapp.
Several sources reference the increased efficiency of using the build-in
function as compared to the same javascript function.

http://couchapp.org/page/faq

http://wiki.apache.org/couchdb/Built-In_Reduce_Functions
http://docs.couchdb.org/en/latest/ddocs.html
http://nosql.mypopescu.com/post/773435732/couchdb-built-in-reduce-functions

Replacing reports-per views with recent-items where possible

- reports-per-android-version => recent-items-by-androidver
- reports-per-app-version-code => recent-items-by-appver
- reports-per-app-version-name => recent-items-by-appvercode
- recent-items-by-bug => recent-items-by-bug-by-installation-id

For these views, and also for recent-items and recent-items-by-installation-id, no longer
capturing the summary data in the view value. Instead, Acralyzer will use the include_docs
option to get the needed data in the browser.
Storing logcat as attachment to crash doc

- makes document storage about one-third smaller
- makes viewindexing about one-quarter faster