Mark added and removed TOML table sections

[Liyu0310-Code]

Fixes #179.

TOMLFormatter.print_MappingNode synthesized [table] section headers from the parent mapping's key segments and printed section bodies from the value mapping's own children, so the Remove / Insert edit on a section's key/value pair had no node to wrap — a whole added or removed [table] rendered with no edit markup while the exit status still reported a difference.

TOMLMapping now tracks whether its section was removed or inserted (propagating through pure-container mappings, whose falsy skip would otherwise drop the flag), and the section writer applies the same markup contexts that Remove.print / Insert.print use — red background + strike and green background + under-plus, with the ~~ / ++ fallbacks when ANSI color is disabled. Section emission is factored into TOMLFormatter._write_section so those contexts can wrap it.

Testing

• Added regression tests: a removed table, an inserted table, and a removed nested table now render with ~~ / ++ markers, and unchanged documents still render without markers.
• Rendered output for documents without edits is byte-identical to master.
• Full suite: 186 passed; the 3 failing tests fail identically on unmodified master on this machine (enumerated and compared).

Disclosure

This PR was generated by an AI coding agent operated by @Liyu0310-Code; the account owner does not review code. Happy to iterate on any feedback.

[ESultanik]

Thanks for this, and apologies for the duplicated effort.

#179 was fixed by #182, which shipped in v0.4.0. On current master:

$ graphtage --no-status --no-color one-table.toml two-tables.toml
[alpha]
x = 1

++[beta]
y = 2

++

Removals render the same way with ~~. TOMLMapping tracks inserted pairs and section bodies go through
SequenceFormatter.print_SequenceNode, which is where the Insert/Remove edits get applied.

This branch was cut before #182 landed, so the two implementations solve the same problem independently. Closing in
favor of the one that's already shipped. Your earlier work on #175/#180 is in the v0.4.0 release notes — thank you for
that, and for this.