v4: Graceful handling of structured config formats (XML, JSON, set-style)

[jtdub]

Description

hier_config currently parses indentation-based (IOS-style) configurations. Several widely-used network platforms represent configuration using structured formats that do not map cleanly to indented text:

• XML — used by NETCONF (Juniper Junos, Cisco IOS-XE RESTCONF, etc.)
• JSON — used by OpenConfig, Arista eAPI, and modern REST-based management APIs
• set-style — flat set <path> <value> syntax used by Juniper Junos CLI and VyOS

Today, users interacting with these platforms either pre-convert the config to IOS-style text (lossy and error-prone) or cannot use hier_config at all.

Proposed Change

Introduce a format-aware parsing layer that can ingest configs in these three additional formats and produce the same HConfig tree used by the rest of the library:

XML / NETCONF

• Parse XML into a hierarchy using element tag names as node text, with attribute key/value pairs as children or annotations.
• Provide a from_xml() or HConfig.load_from_xml() constructor path.
• Handle NETCONF <edit-config> operation attributes during remediation generation.

JSON / OpenConfig

• Parse JSON objects recursively, using key names as node text and leaf values as the terminal line text.
• Provide a from_json() / HConfig.load_from_json() constructor path.
• Handle list-keyed entries (e.g., OpenConfig key leaves) as identifying tokens for idempotent matching.

set-style (Junos / VyOS)

• Parse flat set <path> <value> lines by splitting each line into its path components, building the tree depth-first.
• Emit remediation as set / delete commands rather than indented blocks.
• This may be expressible as a pure driver-level rule (e.g., a FlatSetOutputRule) rather than a separate parser, since the underlying tree structure is equivalent.

Benefits

• Native support for NETCONF/RESTCONF workflows without lossy text conversion.
• Enables OpenConfig and vendor JSON API integrations.
• Improves Junos and VyOS support, which currently require awkward workarounds.
• Keeps the core tree/diff/remediation engine unchanged — format handling is isolated to parsing and rendering.

Breaking Change

No — additive only. Existing indented-text parsing is unchanged.

Considerations

• set-style parsing may be achievable entirely within the existing driver rule system (see v4: Make drivers declarative-only (no method overrides) #222), which would be preferred over a separate code path.
• XML and JSON parsers will likely require a new load_from_* entry point in constructors.py or as classmethods on HConfig (see v4: Consolidate constructor functions into classmethods #218).
• Remediation output format must match the input format (e.g., a config loaded from XML should produce XML remediations, not IOS-style text).
• Round-trip fidelity (parse → remediate → apply) should be validated for each format.