Use non-xxxVF paths in t2cstr when flattening and outputting CFF2

[skef]

Description

handleBlend() in shared/t2cstr.c "handles" flattening by adjusting values on the stack. Because it doesn't copy the blendValues into the opEntry in the flatten mode, you do wind up with numBlends equaling zero in that entry but you wind up with the default in value rather than the blended value.

Perhaps handleBlend() should also adjust the opEntry->value in the flatten case, but I'm reluctant to do that because it seems like the value may be cross-referenced in other places. And while this would fix our stem calculation problems it appears that the curveto case is more complicated and would need additional work.

Anyway, there's no real point to using the blend when we're flattening.

So instead this PR just avoids using the blends entirely when calling out downstream (moveto, lineto, curveto, stemto) in the flattening case. Instead of calling the xxxxVF variant we just call the normal "flat" one. (It also skips the "preparatory" work in t2decode().) That will work fine with CFF2 -- in fact cffwrite does that optimization when there are no blends anyway.

I was going to add a CFF2 instancing test for this but it turns out we don't (appear to?) have any instancing tests right now. So I filed #1587 instead, as what should go into those tests is more than I want to think about while we're sorting through VF hinting.

Checklist:

• I have followed the Contribution Guidelines
• I have added test code and data to prove that my code functions correctly
• I have verified that new and existing tests pass locally with my changes
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation

[skef]

Given the nature of the failures I'm going to assume this is the same windows problem we currently have in develop branch rather than something caused by the (very specific) changes in this PR.

[josh-hadley]

LGTM and I agree that the Windows CI failure is not related to this code at all and should not block this.