Add characterization tests for the LDIF parser (29% -> 70% line coverage)

[opravil-jan]

Depends on #116. Without #116, surefire discovers none of the JUnit 5 tests, so these would not run. Until #116 is merged, its commit also shows up here. Only the test(ldifparser) commit belongs to this PR.

This PR changes tests only; no production code is touched. It pins down the current behaviour of plugins/ldifparser, so that later fixes in the parser cannot silently change anything else.

What is covered

There are 8 new test classes with 62 tests in total. They cover:

• Content records: base64 dn:: and attr:: values (UTF-8), version: lines, comments, multiple records, CRLF and LF line endings.
• Change records: add, delete, modify (add:/replace:/delete: with - separators), and modrdn/moddn with newrdn, deleteoldrdn and newsuperior.
• Controls: with and without criticality, with plain or base64 values.
• Folding: unfolding, toFormattedString at several line widths, and a raw round trip of a mixed file.
• Invalid input, LdifUtils and the LdifFile helpers.

	lines	branches
ldifparser	29.2% → 70.3%	20.3% → 58.1%
LdifParser	23.6% → 84.7%	14.5% → 62.7%
LdifValueLineBase	53.7% → 91.0%	42.3% → 78.8%

Coverage was measured with JaCoCo 0.8.15. Every test class was mutation-checked: I broke one targeted line of production code, confirmed that a test fails, and then reverted the change.

Known and suspected bugs (tests are @Disabled, not cemented)

These tests assert the correct behaviour. Each one fails on the current code for the stated reason (I checked this by enabling them). They are meant to be enabled together with the fix:

Test	Issue
LdifValueLineUrlTest.testFileUrlIsRead	attr:< file:///path is treated as a plain file path (new File(value)), so the value comes back empty
LdifFileFormatTest.testFoldingWithLineWidthOneTerminates	LdifLineBase.fold loops forever for line width 1 (offset = lineWidth - 1 = 0). This test runs in a daemon thread, so enabling it before the fix cannot hang the test JVM.
LdifChangeRecordParserTest.testChangeTypeDeleteAtEndOfFileWithoutEmptyLineIsValid	Only LdifChangeDeleteRecord.isValid() requires a trailing separator line, so a final delete record without an empty line is rejected by the LDIF import
LdifInvalidInputParserTest.testRecordWithGarbageLineIsInvalid	LdifContainer.isAbstractValid() returns true as soon as the first line is valid and never checks the remaining parts, so a record containing a garbage line is reported valid and gets imported

Verification

mvn clean install (Maven 3.9.16, JDK 17): ldifparser has 76 tests, of which 72 pass and 4 are skipped (the disabled tests above).

🤖 Generated with Claude Code