do not use drawRect/drawRRect if path is inversed fill or is not closed
fix path problem in SkLIghtDeferredCanvas
return full layer save strategy from SkLightDeferredCanvas
Add conic curve line tessellation in GrHairLinePathRenderer
avoid data overflow and underflow in convex geomety computation

Intermediate data in computing mass center can result in overflow and
overflow in GrAAConvexPathRenderer.  Use doubles to hold temporary data.
This avoids overflow/underflow at cost of slower math.
Add layer rasterizer for GL

Rasterizer is added into GL by the following:
1. if can_rasterize_via_GPU and can_maskfilter_via_gpu, first rasterize on
   GPU, then mask filter on GPU
2. if can_rasterizer_via_CPU and can_maskfilter_via_gpu, first rasterize
   on CPU, upload to a texture and maskfilter via GPU.
3. if can_rasterizer_via_gpu and can_maskfilter_via_cpu, falls back to 4.
   This is because if we rasterize on GPU, we must download to CPU, do
   mask filtering and then again upload to texture. This is slow
4. if both have to be done CPU, do them on CPU and upload

The followings are not implemented for GL: drawPoints, drawVertices
and draw texts

If a rasterize layer's paint contains mask filter or other rasterizer,
fall back to CPU
create reference/create a scratch texture from a bitmap only it does not have

A bitmap can be backed by a valid texture.  During when converting
a bitmap to a GrEffect from a bitmap shader, we check whether there is
 a valid texture.  Only create/reference a new texture if bitmap does not
have one.

If there is a texture, we must check whether target driver support npot and
tiling.  If not, we need to create a pot texture, paint orig texture to
pot texture
do not draw bitmap directly on non-msaa render target

If AA is specified, and both src and dst rects are not pixel-aligned,
do not draw bitmap on non-msaa render target directly
in drawBitmap(), drawBitmapRect(), drawBitmapRectToRect().  Instead,
we must convert these calls to drawRect() so that it goes to GrAARect or
GrAAConvex renderers
do not optimize draw image if target driver does not support npot

If the target driver does not support npot image, we must create a
pot image, paint the original image to pot image.  In this case,
optimization of image draw does not have much sense because
we have to first draw the pot image. In this case, we disable image
drawing optimization.  Fortunately, most of modern driver (including
es3 drivers) support npot image tiling