[Mac] Rely on science, not chance, to get the proper definition of the macro

[Mac] Rely on science, not chance, to get the proper definition of the macro NSGEOMETRY_TYPES_SAME_AS_CGGEOMETRY_TYPES.

NSGEOMETRY_TYPES_SAME_AS_CGGEOMETRY_TYPES is used in
{Int,Float}{Point,Size,Rect}.h to determine whether to provide distinct
conversion constructors and operators for Foundation NS{Point,Size,Rect} types
in addition to the CoreGraphics CG{Point,Size,Rect} types. When this macro is
defined (as in 64-bit Mac OS X), the NS and CG types are identical and no
additional overloads are needed. When not defined (as in 32-bit Mac OS X), the
types are distinct and additional overrides are needed for the NS types.

This macro is set (or not) by <Foundation/NSGeometry.h>. It is an error to
consider this macro without first #importing this header or its umbrella,
<Foundation/Foundation.h> or <Cocoa/Cocoa.h>. It is also an error to #import
these headers from non-Objective-C code, but in that case, it is impossible to
correctly use the NS types. The net effect is that the overloads for the
distinct NS types will available in Objective-C translation units when the
types are in fact distinct from the CG ones, and not available in
non-Objective-C translation units where they wouldn't be useful anyway, even
if the types are distinct. Where the types are not distinct, the conversion
constructor and operator for CG types is able to handle NS ones as well.

This backs out a previous hack fix for this problem, Blink r169826.

BUG=355576
TEST=compile, both 32-bit and 64-bit

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169976

[eseidel, 2014-03-24 21:30:07]

lgtm, but you may want a more up-to-date-on-mac reviewer than I.

[Mark Mentovai, 2014-03-24 21:31:22]

What’s the most state-of-the-art choice in Blink Mac reviewers nowadays?

[eseidel, 2014-03-24 21:36:27]

I had figured you'd know the answer to that question. :)  I always assume that
you, avi, thakis and now andre know more about Mac than I do at this point. 
It's been almost 8 years since I last wrote mac code professionally.

[Mark Mentovai, 2014-03-24 21:39:51]

All right, then Nico!

(I thought there might have been more of a Blink specialist like in the old
days.)

[Nico, 2014-03-25 18:05:05]

We have a prefix header too, but only for core:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
We tried removing it once, and it made local builds much slower. I wonder if
platform should have a prefix header?

But that seems mostly independent of this CL, so this CL lgtm (except that
chance is in the realm of science, so the CL description is somewhat nonsensical
;-) ). If a prefix header for platform will make local builds faster, that's
even more the case after this change is in.

[Mark Mentovai, 2014-03-25 18:20:18]

The CQ bit was checked by mark@chromium.org

[commit-bot: I haz the power, 2014-03-25 18:20:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mark@chromium.org/208333020/1

[commit-bot: I haz the power, 2014-03-25 19:32:47]

Change committed as 169976