…`Utils.EOL` as deprecated

… which line ending was found during parsing -- this is then used during the lexical preservation csmtoken insertion/diffing to ensure that the "new" newlines are of the same type as the parent....

… separator..

…r one isn't set or it is a meta-value e.g. EMPTY or NONE

…ystem's line ending

…t should be unescaped line separators, but the lookup returns escaped line separators; deprecated isSpaceOrTab and added isWhitespaceButNotEndOfLine as a replacement;

…pace within the grammar (e.g. non-breaking spaces and tab characters)

…arser into issue_2647_eol

… oops!

…r by character). If it is important for you to define the line endings used, provide a LineEnding as a second parameter else use TestUtils#readResourceUsingSystemEol

…ovides more descriptive output from the test's utility method

…ingIgnoringEol, and edited some tests to this.

…gEol`

…`input` meaning that it checks out the code using the repo's line endings not the system's line endings

this was discovered / came up as a problem in javaparser#2685 where javaparser started to respect the line endings of test resources instead of reading line-by-line and inserting the system's line endings

… caller wants the actual line separator "as-is" and without any additional escaping; added human-readable "descriptions" to the LineEnding enums; progress on LineEndingProcessingProvider.java -- now functional and tests passing;

…ost's line separator

…to retaining them

…to retaining them

…tring

…to retaining them