Implemented path operators in a new struct PathProc hooked up to CSOpSet
Added current point to CSInterpEnv

Just to disagree with myself re being done with this code...

Previously, ResourceForkHeader was defined as 30 bytes, having the typeCountM1 as last member.
There was a mysterious offset-by-2 in the code, derived from FontTools and JDK code this was
ported from.

In testing, I observed that typeListZ offset is actually 28.  Suggesting that the typeCountM1
does NOT actually belong to ResourceForkHeader, but belongs to the array itself.  Adjusting for
that resolves the mystery +2 offset hack, so everything is clean and good now.

This, concludes my dfont hacking.  The code looks great now, and I'm happy to leave it.
Fuzzers might disagree though, we will see!

So it doesn't accidentally match our templates, etc.

Offset 0 is not null in this context.

I don't think I broke anything.  Fuzzers will let me know..

FDSelect3/4 sentinel size wasn't taken into account

also some code cleanup

it was causing inconsistent Strings Index subset results

Added OpCode_FontMatrix to TopDictOpSet (yet to parse values)
fixed a wrong assert in encode_int

I have no way to authoritatively know, but looks like test font only has one
face.  So, adjust test expectation instead.

Fixes https://github.com/harfbuzz/harfbuzz/pull/1085

I decided to always use the cache, instead of my previous sketch direction
that was to only allocate and use cache if fast advances are not available.
The cache is a mere 1kb, so just use it...

TODO: Invalidate cache on font size change.

Fixes https://github.com/harfbuzz/harfbuzz/issues/651
Fixes https://github.com/harfbuzz/harfbuzz/pull/1082

Useful for performance testing.

Not hooked to cairo yet.  Just changes shaping, not rasterization.