Correction to fontconfig usage on Unix-not-OSX.

The PhantomJS QPA hardcoded usage of QFontconfigDatabase on
Unix-not-OSX, causing build failures in "bundle all the libraries" mode.
Use QGenericUnixFontDatabase instead, which is QFontconfigDatabase if
fontconfig is enabled, and QBasicFontDatabase if it isn't.  This means
that the bundled-qtdeps build will use only the fonts bundled with Qt,
and won't be able to find them on a machine that doesn't have the source
tree, which is suboptimal, but at least this makes the bundled-qtdeps
build complete successfully again.

Part of issue #12467.
Encode URLs when passing to JS: issues #12216 and #11035.

 * Use QUrl::toEncoded() instead of QUrl::toString() to compute
   WebPage.url, WebPage.frameUrl, the first argument to an
   onNavigationRequested hook, and the 'url' property of the object
   passed to an onResourceError hook.  This makes them consistent with
   the data passed to the onResourceRequested, onResourceReceived,
   and onResourceTimeout hooks, and with the semantics of WebPage.open(),
   WebPage.openUrl(), and the cookie jar.  (Issue #12216.)

 * Use m_currentFrame->baseUrl() instead of m_currentFrame->url() for
   WebPage.frameUrl; this is a partial workaround for a bug in QtWebKit
   which is the root cause of issue #11035.  Noticed while attempting to
   test the above changes.

 * Take care not to mangle the encoding of the url passed to the
   WebServer.listen callback function.  Necessary in order to test the
   above changes: not only should JS receive %-encoded URLs, the server's
   encoding of non-ASCII characters in URLs should be preserved; to test
   this thoroughly, a heinously non-Unicode-compatible encoding (Shift_JIS)
   is deliberately used for the URLs in all the new tests.
Add phantom.resolveRelativeUrl and phantom.fullyDecodeUrl.

These utility functions make it easier to work with encoded URLs.
See issues #12216 and #11035.