SkCodec no longer inherits from SkImageGenerator.

SkCodec no longer inherits from SkImageGenerator.

SkImageGenerator makes some assumptions that are not necessarily valid
for SkCodec. For example, SkCodec does not assume that it can always be
rewound.

We also have an ongoing question of what an SkCodec should report as
its default settings (i.e. the return from getInfo). It makes sense for
an SkCodec to report that its pixels are unpremultiplied, if that is
the case for the underlying data, but if a client of SkImageGenerator
uses the default settings (as many do), they will receive
unpremultiplied pixels which cannot (currently) be drawn with Skia. We
may ultimately decide to revisit SkCodec reporting an SkImageInfo, but
I have left it unchanged for now.

Import features of SkImageGenerator used by SkCodec into SkCodec.

I have left SkImageGenerator unchanged for now, but it no longer needs
Result or Options. This will require changes to Chromium.

Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h
can include SkCodec.h (where Result is), and SkCodec.h does not need
to include it (to delete fScanlineDecoder).

In many places, make the following simple changes:
- Now include SkScanlineDecoder.h, which is no longer included by
  SkCodec.h
- Use the enums in SkCodec, rather than SkImageGenerator
- Stop including SkImageGenerator.h where no longer needed

Committed: https://skia.googlesource.com/skia/+/eb602a5c94078fb2956c9bdc64bbf47a31b9c0e5

[scroggo, 2015-07-07 17:17:15]

scroggo@google.com changed reviewers:
+ djsollen@google.com, emmaleer@google.com, msarett@google.com, reed@google.com,
scroggo@google.com

[scroggo, 2015-07-07 17:17:15]

Per our discussion last week, this severs ties between SkCodec and
SkImageGenerator.

[msarett, 2015-07-07 17:23:51]

lgtm

[reed1, 2015-07-07 20:17:25]

lgtm

[scroggo, 2015-07-09 12:59:27]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2015-07-09 12:59:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1220733013/1

[commit-bot: I haz the power, 2015-07-09 13:03:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-09 13:03:20]

Try jobs failed on following builders:
  Build-Win-MSVC-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...)

[scroggo, 2015-07-09 15:02:37]

Patch set 3 (2 was just a rebase) removes fScanlineDecoder from the
SkAutoTDelete, since that means we need SkCodec.h to include
SkScanlineDecoder.h. SkScanlineDecoder.h already needs to include SkCodec.h,
since Result is in SkCodec, and we cannot have a circular dependency like that.
Instead, manually delete fScanlineDecoder in SkCodec.cpp.

I can think of a couple of other ways to solve this:
- Move Result to its own file (this removes its context though)
- Make the subclass responsible for deleting the scanline decoder (this better
  represents what is happening now, since we detach it in the subclass'
  destructor, but I wanted to make this CL not change behavior. Further, we plan
  to change the lifetime again anyway, so that the caller owns the returned
object
  and it is independent. This would be an unnecessary step to get there.)

[scroggo, 2015-07-09 15:03:26]

The CQ bit was checked by scroggo@google.com

[scroggo, 2015-07-09 15:03:26]

The patchset sent to the CQ was uploaded after l-g-t-m from msarett@google.com,
reed@google.com
Link to the patchset: https://codereview.chromium.org/1220733013/#ps40001
(title: "Manually handle the lifetime of fScanlineDecoder.")

[commit-bot: I haz the power, 2015-07-09 15:03:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1220733013/40001

[commit-bot: I haz the power, 2015-07-09 15:16:07]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/eb602a5c94078fb2956c9bdc64bbf47a31b9c0e5