* Cherrypick crrev.com/333293 (freetype -> freetype-android).
* Update mojo/go/go.py to use android-16 (NDK API level 16), which is
  4.1 (first Jelly Bean). Chromium dropped support for 14.
* TODO (separately): also update tools/go/upload.py and upload new
  binaries?
* Roll android_tools (to match Chromium).
* Small fixes to match //base changes: base::ObserverList, TraceConfig,
  ThreadTicks, etc.
* Restore build/ls.py (and add it to the list of files to not roll).
* Remove the dependency on third_party/instrumented_libraries.
* Add "enable_topchrome_md = false" to build/config/ui.gni.
* Add build/config/ui.gni to files_not_to_roll in
  update_from_chromium.py. (We should probably get rid of the use_glib
  variable/argument, and others as well.)
* Remove mojo/tools/roll/{roll_network_service.py,
  roll_network_service_patches/network_service.patch}. These are for
  rolling from Chromium, whereas we now have/use monet.
* Roll buildtools (to match Chromium).
* Modify sanitizer gn/gni files to make it work (patch included).
  (Maybe the patch even works -- I haven't checked.)

TBR=rockot@chromium.org,jamesr@chromium.org,rogulenko@google.com

Review URL: https://codereview.chromium.org/1180693002.

This factoring will more code use BoxPainter in the future (in particular,
PopupMenu).

R=ianh@google.com

Review URL: https://codereview.chromium.org/1180633004.

Sprite nodes use Point instead of Vector2

Updates sprite test app

Refactors accounting for pivot points in sprites

Adds abstract NodeWithSize class in Sprites.

Refactors SpriteNode to Sprite

Refactors TransformNode to Node (may need to find another name as it conflicts with Sky's Node).

Sprite system now uses and caches transformation matrices.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1180703002.

The final animation is more involved, but this CL starts implementing the menu
animation by making it fade in.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1174253003.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1178783002.

R=chinmaygarde@google.com

Review URL: https://codereview.chromium.org/1178773002.

R=abarth@chromium.org, abarth, hansmuller

Review URL: https://codereview.chromium.org/1181533003

Separate out the raw (directly manipulating sky.view) examples from the rendering (using RenderObject et al) examples.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1173233002

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1169983005.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1163323003.

This isn't perfect, since it makes non-minimal modifications
to the yaml and xml files.  In the yaml case it sorts the keys
and in the xml case it doesn't do the fancy attribute wrapping,
but this seems good enough to use.

R=abarth@chromium.org, johnmccutchen@google.com

Review URL: https://codereview.chromium.org/1179633003.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1165283002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1171573002.

R=eseidel@chromium.org, eseidel

Review URL: https://codereview.chromium.org/1180623003

R=abarth@chromium.org, ianh@google.com, abarth

Review URL: https://codereview.chromium.org/1174203002

This lays the groundwork for using fn widgets in static environments.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1178703002

Dispatch events to fn nodes for each RenderObject that the event goes through, instead of starting at the innermost target and just propagating through our tree.
This starts laying the groundwork for fn disconnected subtrees that are linked together into one RenderObject tree.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1181503002

R=abarth@chromium.org, hixie

Review URL: https://codereview.chromium.org/1181523002

These are now called Block, Stack, and Flex, respectively. Less verbose.

R=jackson@google.com, ianh@google.com

Review URL: https://codereview.chromium.org/1181533002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1181453003

R=ianh@google.com

Review URL: https://codereview.chromium.org/1174153002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1174143002

Previously it was propagating for a constant duration.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1173173002.

Turns out that reintroducing the field in each subclass is probably allocating more storage per node. So let's not do that.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1177483004

Previously, they always started at the center of the RenderInkWell. Now we
remember the local coordinates we computed during the hit test and provide that
information when handling the event.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1180553002.

I'd do it now, but these files are still being used by fn.dart/stocks1, and it's not worth forking the whole animation directory just for this.

TBR=abarth

Review URL: https://codereview.chromium.org/1170033005

I'm starting to spec out a script to make these updates for me
but for now I'm still doing these by hand.

TBR=johnmccutchen@google.com

Review URL: https://codereview.chromium.org/1170863007.

In general, we are hugely inconsistent in what onFoo/onFoo() means.
I'm cleaning out all the cases where onFoo() is a method.

Also, this fixes EditableText, which got missed in the recent syncFields() pass.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1175753003

Fixes https://github.com/domokit/mojo/issues/212

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1173153002.

Previously, we would try to close some Dart persistent handles after destroying
the isolate. Now we revoke the weak pointers these handles are using to refer
to the isolate before trying to tear them down.

Fixes https://github.com/domokit/mojo/issues/233

R=chinmaygarde@google.com, eseidel@chromium.org

Review URL: https://codereview.chromium.org/1175053002.

R=abarth@chromium.org, abarth

Review URL: https://codereview.chromium.org/1176053002

TBR=jackson

Review URL: https://codereview.chromium.org/1178523005

We can use const [] instead and we'll be sure we don't mutate this constant.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1178623002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1176763006

Our current static view_configuration design cannot work.

https://github.com/domokit/mojo/issues/231

R=ianh@google.com

Review URL: https://codereview.chromium.org/1169813009.

The app looks so much better with this on.

R=jackson@google.com, abarth@chromium.org

Review URL: https://codereview.chromium.org/1172413002.

Tweaked the layout in Scaffold a little: the Scaffold
accounts for the (Android) notification bar's height,
instead of the ToolBar. I think it would be best if
moving the app below the notification area were handled
at a lower level. Doing it in Scaffold seemed OK for the
moment, since one could put a ToolBar component anywhere
in an app.

Closes #208

R=ianh@google.com

Review URL: https://codereview.chromium.org/1171173003.

This also removes one bit of magic to make it more obvious what on is
going on during a sync, which should hopefully help.

Components have to decide if they support being stateful or not. If
they do, then they must implement syncFields() and have mutable
fields; if they don't, then they must have final fields. This isn't
particularly enforced, though.

This also renames _willSync() to _retainStatefulNodeIfPossible(), for
clarity, and fixes some minor style issues and one typo that was
breaking the drawer.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1174023003

Remove the usage of base::MessageLoopProxy since it has been deprecated.

BUG=465354
R=viettrungluu@chromium.org

Review URL: https://codereview.chromium.org/1174063002.

Patch from skyostil <skyostil@chromium.org>.

Renders interactive_flex and stocks demos fine. Could use more testing,
so I'm going to work on that after I land this.

R=abarth@chromium.org, abarth

Review URL: https://codereview.chromium.org/1173493003