Validate escape sequences when parsing

[lens0021]

Reverts #732 and re-adds it in parse_escaped_string().

Test

echo "lorem ipsum doloret amat\x10"
trust $ echo \"Hello\" $

[Ph0enixKM]

@lens0021 Thank you for your time and effort. This is a really good PR! Could you please add a compiler directive to disable this warning?

[Ph0enixKM]

@lens0021 This is all good, but what about the rest of the escape sequences?

You can find all the escaped characters in the Bash's repository here in ansicstr located in lib/sh/strtrans.c. This function handles escape sequences. Here we can see that it handles: \a, \v, \b, \e, \E, \f, \n, \r, \t, octal (\0, \1, \2, \3, \4, \5, \6, \7), hexadecimal \x, unicode (\u, \U) and \c for interrupt.

Moreover, for any unrecognized escape sequences Bash copies literally (so for example \d remains \d in the string and not d).

Could you please add missing sequences and adjust the behavior? Since Bash doesn't complain about unrecognized escape sequences, we shouldn't either. Other commands utilize this behavior like sed for Regex where ( means a symbol of opening parentheses and \( means that it opens a group in Regex - even though \( is not a recognized sequence - other commands use this behavior.

[Ph0enixKM]

@lens0021 now that I think about it. Do we actually need to display warning at all? Since there are so many edge cases and existing commands already abuse this Bash's behaviour of copy pasting literally the same escape sequence.

What do you think?