Implementation of all Coord Mappings as GrCustomShaders

Extracted from http://codereview.appspot.com/6251050/, updated to reflect recent commits.

I want to separate committing this code from changes that hook these up and were running into refcounting errors, so that the scope of *that* change can be narrower.

[bsalomon, 2012-05-31 19:18:01]

Overall looks good.

Could we call the files GrGradientEffects (or something like that). I don't know
that CoordMapping is a term that we want to keep around.

http://codereview.appspot.com/6250081/diff/1/src/gpu/effects/GrCoordMapping.cpp
File src/gpu/effects/GrCoordMapping.cpp (right):

http://codereview.appspot.com/6250081/diff/1/src/gpu/effects/GrCoordMapping.c...
src/gpu/effects/GrCoordMapping.cpp:104: const char* fVSVaryingName;
All these long-lived pointers to strings/vars owned by the builder make me feel
sad. I really think a single build function that replaces setupVariables(),
emitVS(), emitFS() would be an improvement.

There is no reason aclass can't create its own non-virtual private emitVS(),
emitFS() that take the vars / names as arguments.

Not saying it should change now, just harping on it.

http://codereview.appspot.com/6250081/diff/1/src/gpu/effects/GrCoordMapping.c...
src/gpu/effects/GrCoordMapping.cpp:253: const GrRadial2Mapping* data =
Do we want an assertion that they agree about whether the gradient is
degenerate.

[TomH, 2012-05-31 19:31:13]

Renamed files and classes.
Added assert, fIsDegenerate member.

[bsalomon, 2012-05-31 19:37:23]

On 2012/05/31 19:31:13, TomH wrote:
> Renamed files and classes.
> Added assert, fIsDegenerate member.

LGTM

[TomH, 2012-05-31 19:40:32]

Committed in r4104.

[TomH, 2012-05-31 19:57:49]

On 2012/05/31 19:40:32, TomH wrote:
> Committed in r4104.

... with API fix in r4105.