Implement SkBaseDevice snapshot support

Implement SkBaseDevice snapshot support

Implement SkImage snapshots for SkBaseDevices. This way filter source
image, eg. the argument of SkCanvas::drawSprite or the resulting device
of save layer can be converted to a SkImage snapshot.

In later commits, this SkImage can be used as input to the filters.

Decouples the following concepts:
* Previously surface associated, now device associated snapshot SkImage
  snapshot
* Surface generation id

For SkBitmapDevice based devices and surfaces, the notification to do
deep copy of the device "backend" (e.g the device backbuffer) is now
SkBitmapDevice::onAccessBitmap and SkBitmapDevice::discard.

For SkGpuDevice based surfaces, each draw operation of the device
checks if the deep copy is needed.

Before, these were intiated upon unneeded SkCanvas::predrawNotify().
(Unneeded, because by definition SkBaseDevice must see all the
modification operations)

For SkBitmapDevice based surfaces, the notification to change
surface generation id is when the device backend bitmap has changed.
This is tracked with SkBitmap generation id.

For SkGpuDevice based surfaces, all device write operations call
SkSurface_Gpu::notifyContentWillChange(), which will trigger surface
generation id change.

Removes redundant SkSurface::notifyContentWillChange(). The contents
change conditions and notifications are internal details of the
subclasses. This call is not useful for Skia clients using SkSurface.
It is also not useful for implementing concrete SkSurface subclasses.

Use new member function SkBaseDevice::newImageSnapshot() instead of
SkBaseDevice::accessBitmap() to refer to the device contents for
filter -related callsites. These callsites will later be modified
to hand the SkImage directly to the filters.

Move canvas->surface association to the device subclasses. This way
the association is more natural:
* One or many canvases refer to one device
* SkCanvas does not know anything about surfaces
* SkBaseDevice does not know anything about surfaces
* One surface-aware device refers to one surfaces
* The surface-aware device knows the concrete type of the surface
  (no upcasting)

Bug=skia:3388

[Kimmo Kinnunen, 2015-02-18 15:09:19]

depends on https://chromiumcodereview.appspot.com/926843003/

[Kimmo Kinnunen, 2015-02-23 14:39:52]

kkinnunen@nvidia.com changed reviewers:
+ bsalomon@google.com, reed@google.com

[Kimmo Kinnunen, 2015-02-23 14:39:53]

so this would be ready for review..

[Kimmo Kinnunen, 2015-02-23 14:41:40]

On 2015/02/23 14:39:53, Kimmo Kinnunen wrote:
> so this would be ready for review..

.. and there's no hard dependencies, though following will fix some problems
exposed by this:
https://codereview.chromium.org/939103002/
https://codereview.chromium.org/951483002/

[reed2, 2015-02-24 23:17:18]

reed@chromium.org changed reviewers:
+ reed@chromium.org

[reed2, 2015-02-24 23:17:19]

How is this CL related to https://codereview.chromium.org/920513003/ ?

There are several core api changes in this CL (e.g. pixelref, device, surface).
Are all of them required? Do any of them stand on their own w/o the rest of this
CL? I'm trying to get my head around the number of changes to the api, but
having trouble.

[Kimmo Kinnunen, 2015-02-25 13:42:28]

On 2015/02/24 23:17:19, reed2 wrote:
> How is this CL related to https://codereview.chromium.org/920513003/ ?

The CL above makes image filters accept SkImage.

This CL makes the SkCanvas / SkBaseDevice subclass produce SkImage instances out
of devices and bitmaps.

I tried to clarify the commit message.
 
> There are several core api changes in this CL (e.g. pixelref, device,
surface).
> Are all of them required? Do any of them stand on their own w/o the rest of
this
> CL? I'm trying to get my head around the number of changes to the api, but
> having trouble.

I tried to split the patch. Please mention if it is still too big and need to be
split further. Any comment about your feeling which part should be separable
would be appreciated.

(This patch was already in split form, but the split patches did not get reviews
either.. Splitting patches on top of rietveld causes much churn (for me) when
the review comments come seldom..)

The bug lists the patch order:
https://code.google.com/p/skia/issues/detail?id=3388