PowerPoint2007 Reader : a shape's text insets come back multiplied by 9525

[dkulyk]

The text insets of a shape are EMU in the file and pixels in the model. The Writer converts; the
Reader does not, so every round trip multiplies each inset by the 9525 EMU of a pixel.

Reader/PowerPoint2007.php:1174-1185 stores the attribute as it stands:

$oShape->setInsetLeft((int) $bodyPr->getAttribute('lIns'));

while Writer/PowerPoint2007/AbstractSlide.php:301-304 writes

$objWriter->writeAttribute('bIns', CommonDrawing::pixelsToEmu($shape->getInsetBottom()));

The defaults show it without any deck being needed. RichText is born with insetBottom = 4.8,
insetLeft = 9.6 -- pixels -- which the Writer turns into bIns="45720", lIns="91440". Written,
loaded and written again on 63f09988a:

	bIns	lIns
written	45720	91440
loaded, then written again	435483000	870966000

435483000 / 45720 = 9525 exactly. A third pass multiplies it again. PowerPoint clamps what it
renders, so the text does not visibly move by 4500 pixels -- the file simply carries a number that
means nothing, and the model hands getInsetLeft() back to the caller in the wrong unit, which is
the part that shows.

The fix is CommonDrawing::emuToPixels() on the four reads, the inverse of what the Writer already
does. PR to follow.

The ODPresentation Reader reads no insets at all, so it has nothing to convert; that is a separate
gap.