Support UTF-8 error message

http://manage.dimagi.com/default.asp?128674#741648
The original error came from trying to convert a unicode string to a byte string using the default encoding (ascii):
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 37: ordinal not in range(128)

So in this case the exception message was a unicode string. It was being converted to a byte string because the format string `'%s'` is a byte string.

Your proposed fix does not seem like the right solution to me. The question is, are the contents of `status_row` expected to be byte strings or unicode? The result of this function is being stuffed into the [return value of a celery task](https://github.com/dimagi/commcare-hq/blob/user_utf_upload/corehq/apps/users/tasks.py#L22), but I'm not sure where that return value goes. My guess is that returning a unicode string is safer since the celery probably takes care of encoding unicode objects if/when it persists the task result. It is less clear what it would do with a byte string with unknown encoding.

I would recommend this instead:
```py
status_row['flag'] = unicode(e)
```
However, there is a possibility that could still fail if the exception message was a byte string containing non-ascii characters (example is for Python 2).
```py
>>> try:
...     raise Exception(u"\xe9") # Unicode works
... except Exception as e:
...     print unicode(e)
...
é

>>> try:
...     raise Exception("\xe9") # bytes fail
... except Exception as e:
...     print unicode(e)
...
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 0: ordinal not in range(128)
```
To be completely paranoid we could to this crufty thing:
```py
try:
    status_row['flag'] = unicode(e)
except UnicodeDecodeError:
    # WARNING we're putting a byte string into the status row, which is probably wrong
    status_row['flag'] = str(e)
```
But that's really just putting a band-aid on another problem, which is that somewhere someone is putting a byte string into an exception message and we have no way to find out how that byte string is encoded, so we can't decode it.