docs: document composition-operator semantics (XOR parity, self-XOR, AND-before-OR precedence)

[Copilot]

Three non-obvious behaviours of U/O/X composition operators were undocumented, regularly surprising AHB authors and consumers. This PR adds the documentation — no behavioural changes.

README — new "Operator Semantics & Precedence" section

• Precedence: U (AND) binds tighter than O/X (OR/XOR). [1] O [2] U [3] parses as [1] O ([2] U [3]), not ([1] O [2]) U [3]. Full precedence ladder documented.
• XOR is odd-parity, not "exactly one of": X chains as a left-associative boolean XOR fold — fulfilled iff an odd number of operands are fulfilled. The trap: [1] X [2] X [3] with all three fulfilled → true.
• Self-XOR is unsatisfiable: [1] X [1] is always false regardless of [1]'s state.

Also updated the existing functionality bullet to reference the new section and explicitly mention XOR in the precedence description.

Docstrings

• LogicalOperator.XOR (enums.py): clarified parity semantics and self-XOR caveat; fixed typo excluxive → exclusive.
• BaseTransformer.xor_composition (base_transformer.py): noted odd-parity and self-XOR in abstract method docstring.
• RequirementConstraintTransformer.xor_composition (requirement_constraint_expression_evaluation.py): added concrete parity examples ([1] X [2] → false, [1] X [2] X [3] → true).

• Fixes docs: document composition-operator semantics (XOR = parity, self-XOR unsatisfiable, AND-before-OR precedence) #813