Email sending implemented

[email send]

I have identified two issues:
- mails sent out get a new Message-ID, which means replies to these
  emails result in broken threads on the heap,
- mails get sent back to the original sender, resulting in two copies
  for that person.
Corrected handling of Msg-ID and IRT in mail send

[email send]

Mail thread structure is now maintained for replies sent via mail as
well as those created on the UI.
Email headers improved

[email send]

Headers have been changed so that mails are sent out via SMTP servers which are
picky on valid envelope 'FROM:' data, like my ISP.

Another improvement is that 'From:' headers contain meaningful information on
the sender.
Added autorefresh feature to conversation views

[autorefresh]

This is not true dynamic HTML, but the effect is similar: if a user
has a conversation displayed (and JS enabled), their window will
refresh whenever it is necessary.

This is implemented in the traditional long poll (Comet) style.
Therefore, it will not work with a single-threaded server, eg. the
default Django development server; you need a multithreaded
installation. See for example:

http://twigstechtips.blogspot.com/2011/05/django-run-development-server-in-multi.html

Once you have taken care of that, the thing will work, but do not
expect a high performance. Traditional web servers are not designed
for high Comet loads, and they will quickly become sluggish and lock
up -- a more mature solution would require an ansynchronous server
like Orbited or Tornado.

Refreshing on incoming mails was a particularly tricky part, since
as of now, SMTP is handled by a separate process, so there was no
easy way to notify the web server except for a dedicated HTTP request.
So, right now, the SMTP process does a GET request to notify the HTTP
process about incoming mails. Of course I do not consider this
anything else but a stopgap measure.

All in all, I did this mainly to inspire myself and perhaps to be able
to show off some of the upcoming features of Hk. Hk is not
production-ready, and this feature is even less so.
Updated code to work with Django 1.5

[django-1.5]

Out of the several incompatibilities, this one was fixed:

"""One deprecated feature worth noting is the shift to “new-style” url
tag. Prior to Django 1.3, syntax like {% url myview %} was interpreted
incorrectly (Django considered "myview" to be a literal name of a
view, not a template variable named myview). Django 1.3 and above
introduced the {% load url from future %} syntax to bring in the
corrected behavior where myview was seen as a variable."""

Admin works fine, even though there were problems on 1.4 with serving static
files. Maybe they reverted this change in 1.5? Further testing on 1.4 is
necessary.
Memoization added to latest_version

[optimization]

Page load times have been crawling upwards recently, and this has
become no longer tolerable, so I implemented this simple solution. It
is by no means a perfect solution to this problem, later (perhaps
after 1.0) we will have to add latest parent info to the model itself.
Merge branch 'memoize' into master-exp