* Use actual exceptions rather than assertions containing code
containing strings when trying to give messages to authors.
* Introduce RenderingError which is an AssertionError that takes a
string argument, to support the above.
* Provide a BoxDimensions.hasBoundedWidth/hasBoundedHeight API.
* Document BoxDimensions.isNormalized.
* Provide more useful information when we assert isNormalized and find
that it is false.
* When finding the size is infinite, crawl the tree to figure out which
render box is likely responsible for the infinite constraints.
* Provide more information when size doesn't match the constraints.
* Provide more information when intrinsic dimension methods violate the
constraints.
* Only spam a huge amount of information for the first exception from
the rendering library. I've noticed a lot of people looking at the
last exception printed rather than the first and that's very
misleading -- after the rendering library hits an exception, all bets
are off regarding what'll happen in the future. All kinds of asserts
might fire.
* Improve docs around the debug methods and flags for the above.
* Make Block default to have no children. Previously, giving no children
crashed with a confusing message about a null deref in an assert.
RenderBlock wasn't constraining the results.
RenderPadding wasn't constraining the results (which matters
especially when the constraints can't fit the padding in the first
place).
RenderViewport wasn't constraining the results.
Add a test for the block case.
To catch this kind of thing in the future, add some asserts to
debugDoesMeetConstraints() that all four intrinsic functions return
values that are within the constraints.
RenderBlockViewport doesn't support returning intrinsics, so turn off
the "no intrinsic support" asserts (and return zero) when we're doing
this new assert.
This new assert screwed up the custom layout classes' tests, so adjust
those tests to ignore the callbacks invoked from these asserts.
Add to the _debugReportException() method a short summary of the
descendants of this node. It's important to have this information when
debugging errors like these intrinsic constraints contract violations
because often nodes just pass the values through to their child so you
have to go several steps down to find the actual problem.
Fixes https://github.com/flutter/flutter/issues/1210
