Build Expat on all platforms

gyp/xml.gyp

Index: gyp/xml.gyp
diff --git a/gyp/xml.gyp b/gyp/xml.gyp
index 36acf97c0122e5e572833b5cb9430db90b7767a0..80600767473c55e3cdef97be728f3f73a245dda1 100644
--- a/gyp/xml.gyp
+++ b/gyp/xml.gyp
@@ -11,6 +11,7 @@
       'standalone_static_library': 1,
       'dependencies': [
         'skia_lib.gyp:skia_lib',
+        'expat.gyp:expat',

[bungeman-skia, 2016/07/14 19:30:04]

hmmm... skia_lib will already have expat built into it in non-framework android
builds and linux builds (to parse fonts.xml). I'm not sure what kind of
headaches that will cause, especially when building skia_lib as a shared lib.

[f(malita), 2016/07/14 19:54:35]

Is that the rule in ports.gyp?  Is it any different from having multiple static
lib targets depend on a common component (expat static lib)?

FWIW I tried a local Linux -Dskia_shared_lib=1 and didn't notice any issues.

[f(malita), 2016/07/14 20:06:38]

Or is it about the system libexpat, which gets linked in for fontconfig?  Should
we do something like this:
https://cs.chromium.org/chromium/src/third_party/expat/expat.gyp?rcl=0&l=8

[bungeman-skia, 2016/07/14 20:08:05]

Thinking about this really hard, we shouldn't run into any issues so long as we
don't pass expat types across the boundary between libs (which we have no plans
to do anyway). In the past we were always running into issues with SkString
where if there are two implementations and an instance from one lib was used in
the other lib bad things would happen (though we asserted on these). Apart from
the duplication of compilation, lgtm.

       ],
       'include_dirs': [
         '../include/private',