Fix handling of surrogate pseudocharacters under Python 3.

[gnprice]

This is a situation where we have a Python unicode string which doesn't
consist entirely of genuine Unicode characters -- some of the codepoints
in the string are surrogate codepoints, which occur in a UTF-16 encoding
of a string and were also repurposed in PEP 383 for losslessly encoding
arbitrary mostly-UTF-8 bytestrings (like Unix filenames) in Python
strings. Currently, on Python 3, we cause a UnicodeEncodeError if we
try to encode such a string as JSON.

It's not 100% obvious what the right thing to do here is -- this
situation seems like it must reflect a bug somewhere else in the
program or its environment. But

• one way we can get such a string is by loading a JSON document
  (perhaps an invalid JSON document? anyway, we load it without error):

>>> ujson.dumps(ujson.loads('"\\udcff"'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 0: surrogates not allowed

• we already pass these strings through without complaint on Python 2;

• as the included test shows, passing these through matches the
  behavior of the stdlib's json module.

So it seems best to pass them through.

Fixes #156.

[hartwork]

I'm not sure if passing through is the best approach — stdlib json does not pass through but escapes (avoiding invalid characters in the output), see:

In [11]: list(sys.version_info)
Out[11]: [3, 6, 10, 'final', 0]

In [12]: json.dumps('\udcff')
Out[12]: '"\\udcff"'

[hartwork]

This code seems unused?

If you're aiming for surrogatepass as a generic solution, it's a recipe for producing invalid UTF-8:

In [6]: '\udcff'.encode('utf-8', 'surrogatepass').decode('utf-8')                                                                                      
[..]
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte

Are you aware?

[hugovk]

Superseded by #530. Thanks!