Try backing SkPicture with SkRecord in Chromium.

This is our first attempt, mostly to feel this out.  Performance and
correctness problems are both possible.  Please revert this if a benchmark even
smells funny.

That said, we've been working on this a while, are pretty confident it's good
stuff, and have had Skia's internal testing entirely switched over for a week.
Parts of Chromium that serialize and deserialize SkPictures are already
switched over.  This CL finishes things off by switching the default
recorded-from-scratch SkPicture to use SkRecord too.

BUG=

Committed: https://chromium.googlesource.com/chromium/src/+/f7450daaf38f4951b23fabaaaf659c6af33a705c

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

Cr-Commit-Position: refs/heads/master@{#292550}

skia/config/SkUserConfig.h

@@ -17,10 +17,6 @@
 #ifndef SkUserConfig_DEFINED
 #define SkUserConfig_DEFINED
 
-// Turns SkPicture::clone() into a simple "return SkRef(this);" as a way to
-// test the threadsafety of SkPicture playback.
-#define SK_PICTURE_CLONE_NOOP 1
-
 /*  SkTypes.h, the root of the public header files, does the following trick:
 
     #include <SkPreConfig.h>
@@ -261,6 +257,13 @@ SK_API void SkDebugf_FileLine(const char* file, int line, bool fatal,
     #define SK_SUPPORT_LEGACY_GETDEVICE
 #endif
 
+// Turns SkPicture::clone() into a simple "return SkRef(this);" as a way to
+// test the threadsafety of SkPicture playback.
+#define SK_PICTURE_CLONE_NOOP 1
+
+// Turns on new (nicer, hopefully faster) SkPicture backend.
+#define SK_PICTURE_USE_SK_RECORD 1
+
 // ===== End Chrome-specific definitions =====
 
 #endif