fix: resolve Python 3.12 SyntaxWarning for invalid escape sequences

[Yusuf-Gadelrab]

Summary

Fixes Python 3.12 SyntaxWarnings for invalid escape sequences in regex string literals by converting them to raw strings. Addresses issue #78.

Testing

• All existing unit tests pass locally after the change.
• No behavior change; only silences 3.12 SyntaxWarnings.

[Yusuf-Gadelrab]

Pushed a follow-up commit that completes this cleanup.

What I missed the first time: the original commit only fixed araby.py. Importing the
package still emitted SyntaxWarning because three invalid escape sequences remained:

Location	Sequence
araby_const.py:271	\w in TOKEN_PATTERN
trans.py:319	\s \d \? \! \( \) in a character class
trans.py:518	'\RL{' LaTeX delimiter in the __main__ demo

Reproduced on master with Python 3.14:

$ python -c "import pyarabic.trans"
pyarabic/trans.py:319: SyntaxWarning: "\s" is an invalid escape sequence. ...
pyarabic/trans.py:518: SyntaxWarning: "\R" is an invalid escape sequence. ...

Verification that the change is behaviour-preserving. For the two trans.py cases the
string literals are byte-identical before and after, so there is nothing to prove. For
araby_const.py the \uXXXX escapes stop being resolved by the Python parser and are
instead resolved by re, so I checked equivalence by differential testing rather than by
inspection: I compiled the old and new patterns side by side and compared finditer spans
and split output over 4,367 inputs (every codepoint in the Arabic block U+0600–U+06FF,
printable ASCII, whitespace and digits, plus 4,000 random mixed strings). 0 mismatches.
I ran the same check against the three patterns from the first commit, also 0 mismatches.

Tests: the seven scripts in tests/ and the 14 tests/unit cases pass before and after.
python -m compileall pyarabic is now free of invalid-escape warnings, where it previously
reported them in two modules.

trans.py CRLF line endings and its UTF-8 BOM are preserved, so the diff is limited to the
three edited lines.

No behaviour change is intended and none was observed; this only silences the deprecation
warning ahead of the escape sequences becoming a hard SyntaxError.