Fix a bug in Save-Restore no-op optimization.

Fix a bug in Save-Restore no-op optimization.

We optimize
    Save
        SaveLayer
        Restore
    Restore
into
    NoOp
        NoOp
        NoOp
    Restore

I'm considering skipping the call to SkRecordOptimize again just to eliminate
this extra variable from landing SkRecord.  Thoughts?

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/99d6a9ee8b3516de892d118c71aa5e6e5c865efd

[mtklein, 2014-09-10 21:16:51]

The CQ bit was checked by mtklein@google.com

[mtklein, 2014-09-10 21:16:58]

mtklein@google.com changed reviewers:
+ robertphillips@google.com

[commit-bot: I haz the power, 2014-09-10 21:17:38]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/560163002/40001

[commit-bot: I haz the power, 2014-09-10 21:17:39]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from a valid reviewer till 2014-09-11 03:17 UTC

[commit-bot: I haz the power, 2014-09-10 22:53:32]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from a valid reviewer till 2014-09-11 04:53 UTC

[robertphillips, 2014-09-10 23:07:05]

lgtm. I think if it is delaying getting SkRecord to stick we should delay it.

[commit-bot: I haz the power, 2014-09-10 23:08:32]

Committed patchset #3 (id:40001) as 99d6a9ee8b3516de892d118c71aa5e6e5c865efd