The problem is that we don't render ShapesWithWrapping.odt
the same as Word does:

https://beta.opendocumentformat.org/rendercompare/upload/223/86/191/1

The first shape in the file is anchored "as-char" and has no
style:vertical-rel or style:vertical-pos attribute affecting it.

If Word would write either style:vertical-rel="baseline" or
style:vertical-pos="top" explicitly, the rendering in LO would
be the same.

So the problem is that, for drawing shapes (note, text frames are
images, embedded objects handled differently), LO's default
vertical alignment is different, it is hard-coded in
SwShapeDescriptor_Impl::GetVOrient() as
SwFormatVertOrient(0, text::VertOrientation::NONE, text::RelOrientation::FRAME)

This effectively positions as-char shapes *below* the baseline,
which, while technically allowed, isn't really a good default.

So fix this by making the default alignment dependent on the anchor
type, so that as-char shapes sit on top of the baseline.

The ODF filter sets the anchor type before inserting the shape in
XMLTextShapeImportHelper::addShape(), however as it turns out the
various MSO filters insert the shape before setting the anchor,
which means the new default in SwXShape has an unwanted effect
on them, as inserting the shape causes the default to be created.

This requires changes to VML import to always set the VertOrient
property, and to RTF import to set the anchor type before inserting.

The DrawingML import is unaffected as it already sets VertOrient
for every non-as-char shape.

The testDmlTextshape "dml-textshape.docx" test still fails, but it
turns out that the change in alignment for this test document is
a bugfix, as it now has the same vertical alignment as in Word,
so adapt the test.

Change-Id: Ifcabd96a037515f7803f5474ec995f968b3b4de1