Change patheffect to take a (new) StrokeRec object, which encapsulates the fill

Change patheffect to take a (new) StrokeRec object, which encapsulates the fill
or stroke parameters for a path.

Today, the patheffect only sees if the caller was going to stroke or fill, and
if stroke, it just sees the width. With this change, the effect can see all of the
related parameters (e.g. cap/join/miter). No other change is intended at this
time.

After this change, I hope to use this additional data to allow SkDashPathEffect
to, at times, apply the stroke as part of its effect, which may be much more
efficient than first dashing, and then reading that and stroking it.

Most of these files changed just because of the new parameter to filterPath. The
key changes are in SkPathEffect.[h,cpp], SkPaint.cpp and SkScalerContext.cpp
Committed: https://code.google.com/p/skia/source/detail?r=4048

[reed1, 2012-05-24 20:38:29]

mirror of rev. 4046 (which was reverted in 4047)

[reed1, 2012-05-24 20:55:56]

need to figure out why GM:pathfill fails sometimes...

[mike3, 2012-05-25 00:06:31]

Found the bug:

SkStroke.cpp

AutoTmpPath -- need to set the fSwap... bool to true in the "if" clause of its
constructor

[reed1, 2012-05-25 01:03:51]

fixed in patchset 3

[bungeman, 2012-05-25 14:00:30]

Stroking needs to come after path effects. Note that previously an 'inner'
stroker could cancel the outer guy (Paint or ScalerContext) from stroking by
mucking with the width. In this case we still want to be able to change the
stroke properties, but we also need to make sure that we don't stoke too early.

https://codereview.appspot.com/6250051/diff/2002/src/core/SkPathEffect.cpp
File src/core/SkPathEffect.cpp (right):

https://codereview.appspot.com/6250051/diff/2002/src/core/SkPathEffect.cpp#ne...
src/core/SkPathEffect.cpp:127: bool SkComposePathEffect::filterPath(SkPath* dst,
const SkPath& src,
It seems that in order for things to work as before, you would need the path
effect to do this self-apply-stroking only when it is the last path effect to be
applied (so that it is as-if the stroke comes after the path effect is applied).
As this is written, it appears that the first path effect with the ability to
self-apply-stroke will do so and then later path effects will get the stroked
version instead of the skeletal version (as they would now).  For example, here
in  SkComposePathEffect it seems that only the 'outer' path effect should do
stroking if it can, while the 'inner' path effect should not do stroking, even
if it can.