Proposal: use MOZ_LOG instead of NS_WARNING for spammy warnings about huge nscoord values

Per this thread...
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/Jw_4xdUTNnY
...some of the top culprits for NS_WARNING-spam are layout warnings for
huge/unconstrained nscoord math.*

I just talked with jet about this, and he suggested we use MOZ_LOG with
an appropriate log-level, instead of NS_WARNING.

I think this is a good idea.  That way, we layout hackers can configure
our environments such that we always see these warnings (if we want to);
meanwhile, our test-runners will have less spam in their logs, and other
developers won't have to see these warnings gunking up their terminals
needlessly, either.

(The downside is, when you're diagnosing a test failure on treeherder,
you might benefit from seeing these warnings; and you can't turn them on
retroactively.  However, given the spamminess level of these warnings,
and given that they're not for particularly flaky conditions [we're
either doing math with these values or we arent'], I'm not sure they're
really all that useful in this use case.)

Thoughts?
~Daniel


* specifically, the nscoord-related warnings that erahm reported as
being in the top 40 are:
{
65959 [NNNNN] WARNING: Overflowed nscoord_MAX in conversion to nscoord
width: file ../../dist/include/nsRect.h, line 83

9201 [NNNNN] WARNING: have unconstrained width; this should only result
from very large sizes, not attempts at intrinsic width calculation:
'psd->mIEnd != NS_UNCONSTRAINEDSIZE', file
glayout/generic/nsLineLayout.cpp, line 884

9155 [NNNNN] WARNING: have unconstrained width; this should only result
from very large sizes, not attempts at intrinsic width calculation:
'psd->mIEnd != NS_UNCONSTRAINEDSIZE', file
glayout/generic/nsLineLayout.cpp, line 3058

9130 [NNNNN] WARNING: have unconstrained width; this should only result
from very large sizes, not attempts at intrinsic width calculation:
'aISize != NS_UNCONSTRAINEDSIZE', file glayout/generic/nsLineLayout.cpp,
line 160

4051 [NNNNN] WARNING: have unconstrained inline-size; this should only
result from very large sizes, not attempts at intrinsic inline-size
calculation: '(mFrameType == NS_CSS_FRAME_TYPE_INLINE &&
!frame->IsFrameOfType(nsIFrame::eReplaced)) || type ==
nsGkAtoms::textFrame || ComputedISize() != NS_UNCONSTRAINEDSIZE', file
glayout/generic/nsHTMLReflowState.cpp, line 448

4050 [NNNNN] WARNING: have unconstrained inline-size; this should only
result from very large sizes, not attempts at intrinsic inline-size
calculation: 'AvailableISize() != NS_UNCONSTRAINEDSIZE', file
glayout/generic/nsHTMLReflowState.cpp, line 360

3897 [NNNNN] WARNING: have unconstrained width; this should only result
from very large sizes, not attempts at intrinsic width calculation:
'NS_UNCONSTRAINEDSIZE != aReflowState.ComputedISize()', file
glayout/generic/nsBlockReflowState.cpp, line 118

3892 [NNNNN] WARNING: have unconstrained inline-size; this should only
result from very large sizes, not attempts at intrinsic inline-size
calculation: 'NS_UNCONSTRAINEDSIZE != computedISizeCBWM &&
NS_UNCONSTRAINEDSIZE != availISizeCBWM', file
glayout/generic/nsHTMLReflowState.cpp, line 2398
}