Fix setEscapeString(null) to clear escape state

[elharo]

Problem

setEscapeString(null) and setEscapeString("") were silently ignored in AbstractFilterReaderLineEnding. When called after a previous non-null value, the old escape string and useEscape flag were retained, so escaping remained active.

Fix

Changed setEscapeString to explicitly clear escapeString to null and useEscape to false when the input is null or empty, and moved calculateMarkLength() outside the conditional so it's always called.

Tests

Added two tests that verify both null and empty string properly disable escaping:

• setEscapeStringNullShouldDisableEscaping -- sets escape to \\, then null, asserts getEscapeString() returns null
• setEscapeStringEmptyShouldDisableEscaping -- sets escape to \\, then "", asserts getEscapeString() returns null

Both tests fail before the fix (expected: <null> but was: <\>) and pass after. All 75 tests pass.

Closes #351

[rmannibucau]

OK for me but wondered why setEscapeString(null) doesn't just throw so can be worth a comment

PS: just realizing than the "plan" (TODO) was to throw on null so really worth an explanation why the "common expected" behavior and original intent are no more valid

[elharo]

I think no NullPointerException here does make sense since most artifacts don't have classifiers most of the time so we need a way to say "no classifier". And even of we threw for null, we still don't want the extra dash for the empty string.

[github-actions]

@elharo Please assign appropriate label to PR according to the type of change.

[rmannibucau]

@elharo this is not strictly related to classifier, did you mixed some other PR or did I miss some context? also can be sane to test the read() method of the interpolator since it will read the first char of the escapestring so covering it is handled is not crazy. Now back to null: empty is enough to disable escaping handling IMHO