Proteus-Zweig: dataset.yaml-Pipeline und 5.0/8.0-Modellbaumvergleich

- create_dataset.py, compare_snapshots.py, rst_to_dataset.py: Proteus-
  Testdatensatz anlegen/vergleichen bzw. aus *.rst-Szenarien extrahieren
- create_dataset.py: Feld-Alias-Fallback (FIELD_RENAMES) für bekannte
  Umbenennungen wie stock.move.uom -> unit, bidirektional
- merge_dedup_rsts.py: Extrahierte YAMLs pro Version zusammenführen,
  versionsinterne Duplikate entfernen, abhängigkeitskorrekt sortieren
- extract_model_tree.py: Modellbaum (Modelle/Felder) statisch aus dem
  Tryton-Quellcode ziehen, für 5.0 und 8.0
- model_diff.py, model_coverage.py: 5.0<->8.0-Modelländerungen finden und
  gegen die aktuelle Testdatenabdeckung abgleichen, priorisiert nach
  tatsächlicher Änderung
- reports/*_merged.yaml: Extraktionsergebnisse für die aktiven
  Module (rohe *.rst-Quellen bewusst nicht mitversioniert)
- Ordner doc ergänzt

README.md

@@ -1,7 +1,24 @@
 # Datenbankmigration von 5.0 auf 8.0
-aktuell zwei Ansätze:
 
-- Codeanalyse des Updatemechanismus
-- Unterschiede im Zustand erkennen nachdem in beiden Versionen die gleichen Testdaten angelegt wurden.
+Ziel: verstehen, wie sich das Datenbankschema der aktiven Tryton-Module
+über die Versionen 5.0 bis 8.0 verändert, als Vorbereitung für die
+eigentliche Migration. Zwei sich ergänzende Ansätze:
 
+- **[doc/UPDATEANALYSE.md](doc/UPDATEANALYSE.md)** – Codeanalyse des
+  Updatemechanismus: statischer Scan der `__register__`-Methoden aller
+  Module über alle Versions-Branches hinweg. _(fertig)_
+- **[doc/TESTDATEN.md](doc/TESTDATEN.md)** – Unterschiede im Zustand
+  erkennen, nachdem in zwei frisch installierten Versionen dieselben
+  Testdaten per Proteus angelegt wurden (Snapshot- und später
+  SQL-Dump-Vergleich). _(in Arbeit - siehe Stand im Dokument)_
+  - dazu als Vorarbeit: **[doc/MODELLVERGLEICH.md](doc/MODELLVERGLEICH.md)**
+    – welche Modelle/Felder gibt es je Version überhaupt, und wo hat sich
+    zwischen 5.0 und 8.0 tatsächlich etwas geändert (steuert, wo sich
+    Testdaten-Aufwand lohnt).
+
+Eigene, von den Standardmodulen abweichende Module (`production`,
+`stock_product_location`, `stock_split`, `stock_lot_sequence`) sind
+bewusst noch nicht Teil dieser Analyse - erst wenn die Standardmodule
+migrierbar sind, werden diese auf 8.0 portiert und die Testdaten-Pipeline
+darauf erweitert.