Don't define log2 and log2f in blink

The consequences are surprising.

A long time ago VC++'s CRT didn't supply log2 and log2f so WebKit/blink
supplied them as inline functions in MathExtras.h. In some cases
(including the full official builds that we ship to customers) this
meant that when Skia called log2f they ended up pulling in blink's
version. This pulled in PeriodicWave.obj which then pulled in various
other object files, and somehow the unreferenced-code logic in the
linker was unable to get rid of all of the rubbish. I noticed this
because during the gyp->gn transition I noticed that ff_cos_131072
and friends were in gn builds of chrome.dll but not gyp builds. I
fixed this but then they came back in full LTCG official builds
(full_wpo_on_official = true). Analysis of a verbose link gave this
chain of events for why rdft.obj (the definer of ff_*) was pulled in:

rdft.obj referenced by
        avfft.obj for symbol ff_rdft_init

avfft.obj referenced by
        FFTFrameFFMPEG.obj for symbol av_rdft_calc

FFTFrameFFMPEG.obj referenced by
        PeriodicWave.obj for symbol public: void __thiscall blink::FFTFrame::doInverseFFT(float *)

PeriodicWave.obj referenced by
        SkGeometry.obj for symbol log2f

Usually the trick to resolving these unwanted symbols is changing a
source_set to static_library, but this time it was recognizing that
SkGeometry has no business pulling in PeriodicWave, and removing the
VC++ definition of log2f that is the culprit. The effect on the size of
chrome.dll is:

chrome.dll
     .text:     -6656 bytes change
    .rdata:       240 bytes change
     .data:   -786624 bytes change
   .rodata:      -592 bytes change
    .reloc:      -872 bytes change
Total change: -794504 bytes

BUG=630755

Review-Url: https://codereview.chromium.org/2559063002
Cr-Commit-Position: refs/heads/master@{#437181}
1 file changed