No font in the corpus carries a GPOS 7/2, so neither applying nor reporting one is ever run

[jakejackson1]

Follow-up to #80 and #90.

GPOS Lookup Type 7 Format 2 is contextual positioning matched against glyph classes - the
positioning counterpart of GSUB 5/2. mPDF has applied it since #80 and reported it since
#90, and neither has ever been run.

A scan of the 103 fonts installed here - tests/data/ttf plus the mpdf/font-bundle-all
packages - finds every other format and not that one:

format	fonts carrying one
GPOS 7/1	1 — NotoSansGurmukhiUI-GPOS71-Subset
GPOS 7/2	0
GPOS 7/3	1 — NotoSans-GPOS73-Synthetic (built by hand for #80)
GPOS 8/1	1 — NotoSansTakri-GPOS81-Subset
GPOS 8/2	1 — NotoSans-Regular
GPOS 8/3	10

So Otl::_applyGPOScontextPosFormat2() (Otl.php:3988) and
OtlDump::reportGPOScontextPosFormat2() (OtlDump.php:2620) are both written from the spec
and from each other, and nothing checks either. #90's own docblock says so:

No font among the 103 installed carries one of these, so what is reported here is read
from the spec and from Otl's applier rather than from a font that exercises it.

Why it is worth fixing rather than noting

#80 hit the same wall for 7/3 and answered it by building
NotoSans-GPOS73-Synthetic.ttf - Noto Sans cut down to A, B and C with a GPOS written by
hand. That font is what lets ContextualPositioningTest state what 7/3 does and
tests/data/otldump/ state what it reports. The same treatment would cover 7/2, and it is
the last format without it.

A 7/2 subtable wants: a Coverage listing the first glyphs, a ClassDef putting them in
classes, and one PosClassSet whose rule names a class sequence and a PosLookupRecord
pointing at a single adjustment. The existing synthetic font is the template - it already
carries the single positioning lookup a context rule needs to delegate to.

What it would cover

• Otl::_applyGPOScontextPosFormat2(), via ContextualPositioningTest and
  tests/data/shaping/
• OtlDump::reportGPOScontextPosFormat2(), via tests/data/otldump/ and OtlDumpTest
• the class-0 handling both share, which is the part most likely to be wrong: class 0 is
  every glyph in none of the other classes, and both sides report or match it as an
  exclusion rather than a list

Doing this before #119 would also mean that sharing the layout decoders has a test for the
one format that currently has none.