Port parts of //third_pary/libjingle build to GN

Port parts of //third_pary/libjingle build to GN

Reimplements parts of //third_party/libjingle's build in GN.

The new build is much less flexible than the original.  Some flags are
not supported.  Some windows-specific configs have been left out and
annotated with TODOs.  Most signifcantly, the entirety of the
'if (enable_webrtc)' block has been omitted, because the GN build
for webrtc isn't working yet.

Despite these limitations, it is an adequate replacement for the
'stub' libjingle target in most situations.

BUG=

[rlarocque, 2014-08-08 19:17:08]

Here's the third_party/libjingle GN work I've done so far.  I had to avoid
importing any WebRTC GN files, since they break the build.  Those build files
are stored in a third party repo, so fixing them will require additional CLs.

Please review.  I'm not sure if it makes sense to commit this as is.  Maybe it's
better to wait until we can convert the entire file?

[tfarina, 2014-08-08 19:50:52]

You say WebRTC breaks the build. Is there a bug filed for this? Is Henrik aware
of this?

Henrik and Brett fyi.

[rlarocque, 2014-08-08 20:03:36]

On 2014/08/08 19:50:52, tfarina wrote:
> You say WebRTC breaks the build. Is there a bug filed for this? Is Henrik
aware
> of this?

It was my understanding that the GN-ification of WebRTC was still in progress,
so I wasn't too surprised that it wasn't working.  I figured if it was complete,
then someone would have added //third_party/webrtc to the "root" group to
prevent regressions.

[awong, 2014-08-08 21:53:15]

Need to review more but had 2 comments I wanted to send first.

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
File third_party/libjingle/BUILD.gn (right):

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
third_party/libjingle/BUILD.gn:8: libjingle_source = "source"
Do we know why these are necessary?

I'm tempted to suggest not adding in this flexibility until
third_party/libjingle shows how we need to flex. Then we can figure out how best
to structure the GNs.

For example, I feel like the BUILD.gn should be in the source directory.

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
third_party/libjingle/BUILD.gn:30: "./overrides",
I don't think you need the ./ in front of these paths, do you?

[rlarocque, 2014-08-09 00:01:11]

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
File third_party/libjingle/BUILD.gn (right):

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
third_party/libjingle/BUILD.gn:8: libjingle_source = "source"
On 2014/08/08 21:53:15, awong wrote:
> Do we know why these are necessary?
> 
> I'm tempted to suggest not adding in this flexibility until
> third_party/libjingle shows how we need to flex. Then we can figure out how
best
> to structure the GNs.
> 
> For example, I feel like the BUILD.gn should be in the source directory.

I had assumed it was related to some other embedder of libjingle, but I can't
find anything similar in the upstream repos.  Maybe Henrik knows why it's here.

I'm definitely in favor of getting rid of this variable, if possible.

I can see some room for objection on moving this file down one level, though. 
There's a handful of sources in the .gyp live in the overrides directory, which
is a sibling of source.  If we end up porting those sources, then we'd end up
with

sources = [ "../overrides/foo.cc" ]

which looks a little odd.

It's only two or three files, so maybe we can live with it.  But I have a slight
preference for leaving this BUILD.gn file where it is.

https://codereview.chromium.org/455583002/diff/60001/third_party/libjingle/BU...
third_party/libjingle/BUILD.gn:30: "./overrides",
On 2014/08/08 21:53:15, awong wrote:
> I don't think you need the ./ in front of these paths, do you?

Correct.  That's not necessary.  Fixed.

[kjellander_chromium, 2014-08-14 06:12:53]

On 2014/08/08 19:50:52, tfarina wrote:
> You say WebRTC breaks the build. Is there a bug filed for this? Is Henrik
aware
> of this?
> 
> Henrik and Brett fyi.

It's correct that all of WebRTC that Chromium uses is not ready for GN yet. 
This is tracked in http://code.google.com/p/webrtc/issues/detail?id=3441
I have a CL prepared in https://codereview.chromium.org/321313006/ that enables
//third_party/webrtc in src/BUILD.gn, 
but I still haven't caught up with recent changes (like the boringssl switch) in
the GN files, since I'm on parental leave.