Base64Field in Djblets 2.0 was updated for Python 2/3 string

compatibility, but it ended up returning the wrong string type when

preparing data for the database. It generated Base64 content, which

comes in the form of a byte string, and returned it for storage. This

was handled fine by SQLite and MySQL, but Postgres replaced it with a

literal \x (2 byte string, not the escape code). Upon loading the data

again, this would lead to an error about invalid Base64 content.
The correct thing to do was to return a Unicode string. On Python 2,

either byte string or Unicode strings are handled fine as a return

value, so long as the database backend can handle the content. On Python

3, the string type seems to heavily depend on the backend. Since we're

storing pure ASCII content (Base64 encoded value), a Unicode string is

the safest option.
Since Djblets 2.0 went live, and we've had some customers test an

install of Review Board 4.0 that ended up breaking due to this bug, we

need to ensure we're compatible with this bad stored data. We now look

for this when pulling from the database, and if we see it, we turn it

back into an empty string.

Unit tests pass on all versions of Python.
Manually tested the failure condition (storing an empty byte string) on

SQLite, MySQL, and Postgres. Verified it only failed on Postgres.
Manually tested the fix on all, and the workaround for loading the

previously-stored bad data on all.