[lldb/test] Fix for flakiness in TestNSDictionarySynthetic

[JDevlieghere]

Summary:
TestNSDictionarySynthetic sets up an NSURL which does not initialize its
_baseURL member. When the test runs and we print out the NSURL, we print
out some garbage memory pointed-to by the _baseURL member, like:

_baseURL = 0x0800010020004029 @"d��qX"

and this can cause a python unicode decoding error like:

UnicodeDecodeError: 'utf8' codec can't decode byte 0xa0 in position
10309: invalid start byte

There's a discrepancy here because lldb's StringPrinter facility tries
to only print out "printable" sequences (see: isprint32()), whereas python
rejects the StringPrinter output as invalid utf8. For the specific error
seen above, lldb's isprint32(0xa0) = true, even though 0xa0 is not
really "printable" in the usual sense.

The problem is that lldb and python disagree on what exactly is
"printable". Both have dismayingly hand-rolled utf8 validation code
(c.f. _Py_DecodeUTF8Ex), and I can't really tell which one is more
correct.

I tried replacing lldb's isprint32() with a call to libc's iswprint():
this satisfied python, but broke emoji printing :|.

Now, I believe that lldb (and python too) ought to just call into some
battle-tested utf library, and that we shouldn't aim for compatibility
with python's strict unicode decoding mode until then.

FWIW I ran this test under an ASanified lldb hundreds of times but
didn't turn up any other issues.

rdar://62941711

Reviewers: JDevlieghere, jingham, shafik

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D79645

(cherry picked from commit f807d0b)

[JDevlieghere]

@swift-ci please test macos

[JDevlieghere]

For https://ci.swift.org/view/LLDB/job/oss-lldb-incremental-osx-cmake/

[adrian-prantl]

👍

[vedantk]

LGTM. I've been trying to merge this for 10+ days, but kept hitting Linux PR testing failures..