OpenXML: handle fldChar fields correctly

[Chase Tingley]

Attached is a sample with a single field that looks like this:

This file is called [filename].

where [filename] is a field variable that inserts the name of the current file. The markup for this uses the <w:fldChar> structure, which spans several runs and encodes both the field codes as well as the cached current value of the field (which, in this case, is "fldChar.docx").

When we extract this to XLIFF, we get tag soup:

<g id="1">This file is called </g><x id="2"/><x id="3"/><x id="4"/><g id="5">fldChar.docx</g><x id="6"/><g id="7">.</g><x id="8"/>

The "fldChar.docx" value should not be exposed for translation, because it's a cached/computed value and will be recalculated by Office. The field definition should not be exposed for translation because it's an Office-internal macro language.

The entire field code, including the cached value, should be represented as a single tag.

[Chase Tingley]

This should also handle fldSimple, which behaves slightly differently.

[Chase Tingley]

Added a testcase of fldSimple -- the footer contains a date field.

[Chase Tingley]

I've discovered that these delightful codes can be nested. For an example, see the "table of contents - automatic.docx" unittest file.

[Chase Tingley]

Fixed on tag-rework branch

[Chase Tingley]

Fixed in M29.