First-class support for <group> and <bin-unit> structural elements

Today `Xliff::File` models `` as a flat list of `` entries. Following the #15 review, `` and `` children are preserved verbatim on round-trip (`Xliff::File#unparsed_body_nodes`) but are not parsed — so their nested ``s aren't reachable through the API (`entries`, `entry_with_id`, `add_entry`).

First-class support would model these structural elements rather than treating them as opaque nodes:

- `` nests ``, ``, and `` recursively, and carries its own attributes (`id`, `datatype`, `xml:space`, `restype`, `resname`, …) and optional `` / `` / ``.
- `` has `` / `` (inline base64 or an external skeleton reference) plus notes, and may itself contain `` children.

This is a data-model change, not an addition: `File`'s flat `entries` array becomes an ordered tree, and the public API needs group-aware traversal (or a documented flattening) so `entry_with_id` and friends reach nested units. Serialization and a large new test surface come with it.

## Scope

Split out of the #15 review. The library's target input — Xcode `.xliff` exports — uses `` directly under `` with no groups, so this isn't required for that use case; verbatim preservation already prevents data loss. This issue tracks the larger modeling effort.

Start by reading Xliff::File and its entries, entry_with_id, add_entry, and unparsed_body_nodes APIs to understand the current flat-body model and round-trip behavior. Define the tree model and traversal semantics for nested group and bin-unit elements, then add serialization coverage showing nested structures and verify nested trans-units are reachable through the public API.

Written by the indexing model from the issue text.