Define a tested BibLaTeX structural compatibility profile #586

Problem

The documentation says that BibLaTeX and Biber data sources should be parseable because they share the general BibTeX syntax, but the suite does not define a concrete compatibility profile. That makes it easy to regress richer records while testing only traditional BibTeX entry types and fields.

The missing contract includes the @set support requested in #105, but is broader:

• @xdata inheritance containers and xdata references;
• BibLaTeX entry types such as @online and @software;
• date ranges, UTF-8 values, related-entry fields, and entry sets;
• Biber data annotations and extended name forms; and
• entry-type and field names supplied by custom Biber data models.

Proposed contract

Add one synthetic, non-personal fixture and tests that require the default structural parser/writer to retain entry types, keys, field names, values, and source order across a canonical round trip. The parser should remain schema-agnostic: unknown types and fields are data and should not require a BibLaTeX dialect flag.

Document the boundary clearly. Structural preservation does not mean that this package validates a BibLaTeX data model, resolves @set or @xdata semantics, or interprets names, annotations, dates, and lists as typed values. Biber remains the semantic validator/processor.

The tests depend on preserving entry-type spelling as proposed in PR #570. Biber-style nested comments remain the separate parser feature tracked in #372 / PR #585.

Conversion between BibTeX and BibLaTeX should not be part of this change. Because the data models are not generally losslessly equivalent, conversion needs a later opt-in mapping profile with explicit loss reporting.