Refactor: xml: no libxml serializer reinventing in generic crm_xml_dump

Generally, there's the only use case where it's desirable to reinvent
such wheel, since it's also the only direct route to hook into
particular step in tree traversal -- when some enumerated attributes
are to be suppressed, as happens to be done in digest calculation
path (except for scheduler itself), which is sort of special.

On the other hand, there's a bad track record of generic XML format
mishandling (can be summarized as sudden surprises when anything
beyond proper subset of XML assumed internally is hit, mostly owing
to the lack of unit tests), so it's advisable to stay conservative
at this time, flip the perspective initially and only defer to the
full-fledged serialization for single use case only -- for when
text nodes are acceptable at the output (that is, just in
dump_xml_formatted_with_text function). Another actual reason is
performance -- when XML serialization change was extended to what
crm_simulate uses, there was a penalty of 5 seconds, or 3.5% slower
run for a complete cts-scheduler suite execution.

For all other use cases (incl. said legitimate one), stay with the
legacy tested&trusted internal implementation. But note for instance,
when a new (so far neglected, like namespaces) facet to XML is to be
utilized anew and pertaining the code path that has just been turned
into libxml serializing option, all the wheel reinventing code would
need to be updated (made closer to full-fledged implementation in
libxml), which is a waste (presuming such facets won't be needed for
said legitimized cases). On another note, compatibility for
xml_log_option_text and its original behaviour (see 524c4d670) is
intentionally preserved at this time, also to allow for some emergency
contingency.

Code-maintenance-wise, this change is actually just a grooming, since
a pre-existing, buggy and commented out code received a proper care
... and became thus production ready.