Lower pre-allocations of Skia's matrix+clips in SkCanvas

With the default settings, every SkCanvas allocation has 3k of RAM
allocated for clips and matrices used on save/restore calls. Chrome
allocates SkCanvas (typically subclasses like SkNoDrawCanvas) many
times during a typical user journey (thousands per minute of browsing).
Few of these canvases exist at the same time; most are very short lived.

Prior to 2015 [0] the default was 8 due to the deferred save
count optimization landed before then [1]. [2] landed in Skia
to make this configurable instead of shared between potentially
competing clients.

I instrumented skia internals to see what the max size of the
MCStack was and found that 90% of the SkCanvases in my sample
had a depth of 16 or fewer. 93% had a depth of 32 or lower.

By lowering the default for Chromium, we will save about 1k of RAM
in 90% of SkCanvases and 3% of the time will need an extra malloc
call. That seems like a reasonable tradeoff, but we'll keep an
eye on our benchmarks for perf changes.

[0] https://codereview.chromium.org/1450093002
[1] https://codereview.chromium.org/767333002
[2] http://review.skia.org/931823

Change-Id: Id11370b15677cab149b1b62aec1ea57346f51b45
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6114605
Commit-Queue: Kaylee Lubick <kjlubick@chromium.org>
Auto-Submit: Kaylee Lubick <kjlubick@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1399317}

skia/config/SkUserConfig.h

@@ -138,6 +138,12 @@
  */
 #define SK_PDF_USE_HARFBUZZ_SUBSET
 
+/*  This controls how much space should be pre-allocated in an SkCanvas object
+    to store the SkMatrix and clip via calls to SkCanvas::save() (and balanced
+    with SkCanvas::restore()).
+*/
+#define SK_CANVAS_SAVE_RESTORE_PREALLOC_COUNT 16
+
 // Handle exporting using base/component_export.h
 #define SK_API COMPONENT_EXPORT(SKIA)