Fixing SkPicture serialization

Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code

BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com

Author: sugoi@chromium.org

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

git-svn-id: http://skia.googlecode.com/svn/trunk/src@13764 2bbb7eff-a529-9590-31e7-b0007b416f81

• core/SkPicture.cpp[diff]
• core/SkPicturePlayback.cpp[diff]
• core/SkPicturePlayback.h[diff]
• core/SkValidatingReadBuffer.cpp[diff]
• core/SkValidatingReadBuffer.h[diff]
• ports/SkGlobalInitialization_chromium.cpp[diff]
• ports/SkGlobalInitialization_default.cpp[diff]