Fixes flutter#175074

There was an implicit expectation in the resizing code: When the virtual
keyboard is up on mobile, the view's `physicalSize` remains fixed, and
any resizes (presumably caused by the virtual keyboard itself) should be
considered as `viewInsets`.

This expectation was broken inadvertently by my PR:
flutter#172493

<hr>

The sequence of events that lead to the reported issue:

1. View's physical size is calculated based on window size.
2. Text editing starts, virtual keyboard comes up.
3. View's physical size remains unchanged, and the difference caused by
the keyboard is reported as view insets to the framework.
4. (so far so good).
5. When `resizeToAvoidBottomInset` is true, the framework will re-render
its content to fit the available size.
6. The new render call comes with a new size that's basically `physical
height - bottom inset`.
7. The engine takes that new size and applies it to the DOM.
8.  (now the view's DOM element has been resized incorrectly).
9. ...
10. Eventually, this leads to the new insets being calculated
incorrectly resulting in negative insets which cause the framework to
throw.

<hr>

The fix involves the following:
1. Respect the expectation mentioned above: when the keyboard is up,
view's physical size should remain unchanged.
2. *_If_* we ever end up with negative insets, catch it earlier in the
engine so it's easier to debug the root cause.
3. New regression test.