Resolve a percentage odf margin, and give AnchorType a neutral value

[andiwand]

The two items #881 left open.

A percentage fo:margin was dropped

[OpenDocument] 16.2 resolves a percentage against the same property in the
parent style — which is why LibreOffice writes fo:margin="100%" to mean
"whatever the parent had", alongside explicit fo:margin-left="0cm".

So my note on #881 was wrong: passing it to css would be wrong twice over,
because css reads % there as the containing block's width. A table of
contents would have got a margin the width of the page. It resolves against the
parent now, as fo:font-size beside it already did — Style's constructor
copies the parent's resolved style in before resolve_style_ runs, so the
value to scale is already there.

The corpus renders byte for byte as before, and that is the point: every
100% in it resolves to exactly the parent value the drop used to leave
standing. No reference regeneration needed. What changes is the case that was
silently wrong — 50% over a parent margin now halves it instead of inheriting
the parent's full value.

AnchorType had no neutral value

Frame::anchor_type() on a frame that does not exist answered as_char, which
a real frame also answers, so a caller could not tell them apart. It gains
none as its first value, the way ShapeType has one.

Breaking: every ordinal after it shifts by one. enum_ordinals_test.cpp
pins the C++ side, apple's ODR_SAME_ENUM pins its mirror at compile time, and
jni's AnchorType.java resolves by ordinal(); wasm does not bind this enum.
Appending would have been silent but reads wrong next to ShapeType::none, and
a major is where this belongs.

Checks run

C++ 1689 passed. Reference output byte-identical in both repos, from a fresh
full run in the test directory. python 81, jni junit, apple 40 XCTest. Both
touched TUs clean under g++-15 -Wall -Wextra -Werror -fsyntax-only.