Resurrect the special hack "lcl_SubtractFlys" that effectively paints
"lower" flys on top of "higher" flys, defying the z-ordering, if the
lower fly is *anchored* in or at the higher fly.

It turns out that this is not obvious to emulate in any other way that it
is currently implemented:

One idea would be to split up painting of the fly background from the
foreground, by creating 2 different view objects per fly as children
of the SdrPage when decomposing it in svx; but the problem is, they will
be ordered in z-order of the flys, and the point would be to paint the
backgrounds first and in a different order, call it "anchoring order".

What that order should be is hard to tell, there is a conflict between
the defined z-order and the flys that are part of one "anchoring
hierarchy" and should have their backgrounds re-ordered, because
entirely unrelated flys that could belong to different "anchoring
hierarchies" but overlap the first ones may result in a cyclic ordering.

Painting one "anchoring hierarchy" recursively would not get
z-order of flys from different anchoring hierarchies right.

Another difficulty is that heaven-layer backgrounds would need to be
painted before hell-layer ones.

Another aspect of the lcl_SubtractFlys is that it entirely ignores
drawing shapes; only Writer's own flys are handled.

Since none of the above makes much sense, we clearly want to
deprecate the lcl_SubtractFlys rendering.

Introduce a new compatibility flag "SubtractFlysAnchoredAtFlys" so that
the legacy rendering is only active for legacy documents, while new ones
remain free from its taint.

(regression from 6e61ecd0)

Change-Id: I710fe79710b89c8f865ebb7162e14713aac6cc4a