Had to adapt EscherPropertyContainer::GetPolyPolygon due
to it using conversions from UNO API drawing::PointSequence
to old tools::polygon, containing unsafe memory accesses.
It is not useful to fix that, use new tooling instead.

Before correctly testing nCount for zero in b2dpolygontools.cxx
when you look closely always a point was added - a random
one due to accessing random memory.
This is corrected, so in test case for "tdf104115.docx"
a PolyPolygon with two polys is used, the first being
empty (had one point due to the error mentioned above).
When having no points, CreatePolygonProperties in escherex.cxx
does badly calculate and alloc the pSegmentBuf array used
to write to doc formats (in the test case - 20 bytes alloced,
22 written). This did not happen before due to having
always a point due to the error before - argh!
Corrected that and hopefully this will work now.

To be on the safe side and to not need to redefine that whole
CreatePolygonProperties I will turn back that little change
and better sort-out empty polygons inside GetPolyPolygon
alrteady. That should bring us back to the original state,
at the same time avoiding that CreatePolygonProperties has
to handle empty Polygons at all.
That stuff urgently needs cleanup - I took a look and thought
about using std::vector<sal_uInt8> so no wrong alloc or write
too much could happen, but that nTotalBezPoints needs to be
pre-calculated because it gets itself written to that
buffers...

Change-Id: Iefc885928f5bb29bceaf36c2a1555346bb21fd26
Reviewed-on: https://gerrit.libreoffice.org/56927
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>