Fix #553 Fix #537 xml-fallback and unbooked-xml transactions

[lukas-staab]

This PR fixes Issue #553 (xml Fallback did not work properly and was very brittle) and also #537 due to symetry reasons (xml had no unbooked transaction till now)

I am 100% backwards compatible by the exposed Action Methods, but some things did change / are opinonated:

• XML is the new default GetStatementsOfAccount Method, if available. Before it tried to do MT940 and if it failed used XML as a fallback, I turned that around. MT940 is deprecated by Deutsche Kreditwirtschaft.
• The XML version got its new own getStatements() method, which uses the Transformer which was already in the project, but well hidden (for me). IMHO the getStatements() structure leaves a lot to be desired for XML dataentries, but this should be a different discussion i opened Feat: Introducing new Data Classes for CAMT XML transactions #579 for that.
• (unfinished) serialized actions before this patch are not recoverable after it. It would be doable in code but its quite a bit of code for not much impact, when you can just restart the action once.
• I deprecated (not deleted) a couple of methods on GetStatementOfAccount. The naming is IMHO all over the place and should be restructured in a future fix; therefore i deprecated (not deleted) them. I Introduced getRawResponse() as the new way forward. It might be intrested to differentiate between booked and unbooked there, but that would need further changes. We could discuss this before a new release.
• I also fixed a bug in the CAMT parser (src/CAMT/CAMT.php): camt.052.001.02 through .06 spell the booking status as a plain code (<Sts>BOOK</Sts>), while .08 makes it a choice element (<Sts><Cd>BOOK</Cd></Sts>) - and only the plain form was read, so every transaction was reported as not booked. Little exposure so far - CAMT parsing only landed in Add CAMT XML parser with automatic MT940 fallback #533 (released with 4.1 in May) and the converter was reachable only through the broken fallback - but this PR puts that path on the main road, so it should be adressed here imo. Maybe also discussed if we want to use an external lib instead of self implementing (and maintaining) camt parsing?

<!-- .02 through .06 -->
  <xs:element name="Sts" type="EntryStatus2Code"/>
  <xs:simpleType name="EntryStatus2Code">
    <xs:restriction base="xs:string">
      <xs:enumeration value="BOOK"/><xs:enumeration value="PDNG"/><xs:enumeration value="INFO"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- .08 https://github.com/genkgo/camt/blob/56e047d1599854ca34db0ccabce15230fcdd3f16/assets/camt.053.001.08.xsd#L699 -->
  <xs:element name="Sts" type="EntryStatus1Choice"/>
  <xs:complexType name="EntryStatus1Choice">
    <xs:choice>
      <xs:element name="Cd" type="ExternalEntryStatus1Code"/>
      <xs:element name="Prtry" type="Max35Text"/>
    </xs:choice>
  </xs:complexType>

AI-Disclaimer

The changes implementations are planed by me and hand reviewed and tested afterwards, and quite some time was invested during the design Phase but ultimately AI-written with a payed subscription via Claude Code Opus, especially tests and commit messages

---

Also related to #463, #577. Does NOT fix #572 (only a similar error message; through GetStatementOfAccount the delegate now receives the request segment numbers, so that path reports the exception instead of running into a fatal - users of GetStatementOfAccountXML directly see no change).

[simonschaufi]

Can you not shorten the description to the most important information? It's way too much text to read in my opinion.

Please also explain what resources you used to implement this change. How does your AI know the standards?

[leobeal]

@lukas-staab I think this PR is doing too many things.
If you want it to be reviewed by the right people - and merged, I suggest you break it down in small PRs.

For breaking changes, I suggest you explicit mention what breaks and why. These should of course be a separate PR. "I tried to be 100% backwards compatible, but some things did change:" is not very reassuring.

[lukas-staab]

@simonschaufi thanks for your Feedback; i did. I will open the discussions mentioned as future PR or Issues, i will think about it.

Please also explain what resources you used to implement this change. How does your AI know the standards?

About which part of the code are specifically talking? I can only think about the booking flag, i updated the description about it ... The rest of the code does not need to know much about the specification documents; its mostly cleanup and connecting code which was already there but not fully integrated.

@leobeal Thanks, i reviewed it as well again, i dropped the php increase, which was not much worth here and quite some noice looking at it after some sleep. I also clarified some things in the text. There is no breaking change which could be seperated; maybe the defaulting to xml, but MT940 is deprecated, so ...

If you have anything else in mind which you think i should split up let me know, i am open for suggestions. I could only think of the camt parser bug or xml unbooked, but its only 2 lines each, and the second one split up would introduce some un-symetrical feature sets

[lukas-staab]

I regrouped the same original code changes in 4 different commits, hopefully this gives better reviewabilty :)