This is a combination of 6 commits.

This is the 1st commit:

oox smartart, cycle matrix: fix counting presentation children

The markup is:

<dgm:if name="Name6" axis="ch ch" ptType="node node" st="1 1" cnt="1 0" func="cnt" op="gte" val="1">

Where PowerPoint evaluated the condition to true, but Impress evaluated
to false. This means that the undocumented relation between the child
lists is "OR" (not "AND").

Also, our code assumed that "node" has to be a data node (not
presentation node), but it seems the only way this condition can be true
if presentation children is also counted. (The presentation node in
question is not a presentation of anything.)

(cherry picked from commit e3c6f249)

This is the commit #2:

oox smartart, cycle matrix: handle left/bottom constraint in composite algo

The bugdoc has 3 shapes in the "outer" circle which have a position
where either x or y is not 0. But these are defined using constraints
talking about the right or bottom edge of the shape.

Map that to top/left, given that we already know the shape size.

(cherry picked from commit b9b4e922)

This is the commit #3:

oox smartart, cycle matrix: fix too large height in composite algo

The user-level problem was that the height of the entire smartart was
too large. The reason for this was that:

- composite algorithm gets the constraint height should be 77% of width,
  this means 6096000 -> 4693920 EMUs

- at the same time the parent container is already smaller, 4064000 EMUs

- a few lines later we already limit the max height with std::min(), but
  in the meantime an incorrect y position is calculated, exactly due to
  the lack of early limited height

Solve the problem by making sure composite algorithm never works with a
height (even when using it to calculate vertical center) that exceeds
the height of the parent.

(cherry picked from commit 5b2e38e0)

This is the commit #4:

oox smartart, cycle matrix: handle aspect ratio in composite algo

This way the 4 quadrant shapes in the center of the SmartArt form a
circle, as width is shrinking.

It's not height growing, as OOXML spec clearly says "ar" always just
shrinks one axis.

(>1 and <1 "ar" is to be handled when they are seen in action in an
actual document.)

(cherry picked from commit 34383064)

This is the commit #5:

oox smartart, cycle matrix: handle destination order in connections

It is possible to have connections from multiple data nodes to the same
presentation node with a presOf type. We use to order these based on as
they appear in the data XML, but we need to order them according to the
destOrd attribute.

Introduce an std::map for that, so get ordering automatically as we
iterate. Turn the std::pair into a struct to make the code a bit more
readable.

(cherry picked from commit ecb733da)

Conflicts:
	oox/source/drawingml/diagram/diagramlayoutatoms.cxx

This is the commit #6:

oox smartart, cycle matrix: fix fill and line props of shape

The topmost shape may not have 0 depth, but something larger.

In that case at least it's safe to still use fill & line properties. The
B1 quadrant of the test file now has the proper orange background, and
B2's border is also properly orange.

(cherry picked from commit 8193e697)

Conflicts:
	oox/source/drawingml/diagram/diagramlayoutatoms.cxx

Change-Id: Iccc5f6993693a0f1cf8f50d163003c24d3ad690e
Reviewed-on: https://gerrit.libreoffice.org/68144
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>