fix #187: escape backslash in param encoding to fix newline in ViewId/state

[hezhenxing]

Previously, sanitizeParamText and desanitizeParamText did not escape the backslash character itself. This caused a collision: JSON's escape sequence for a newline character (the two chars '' and 'n', written as \n in JSON) was indistinguishable from the param encoding's escape for a real newline.

When a ViewId contained a list of Text with newline characters (e.g. Message ["\n"]), the list was JSON-encoded to ["\n"], and then desanitizeParamText would convert \n back into a real newline inside the JSON string, producing invalid JSON. The subsequent parse failure meant no handler matched the viewId, giving the error:
"No Handler for Event viewId when view id or state data has new line character"

Fix: escape backslash first in sanitizeParamText (\ → \), and unescape it last in desanitizeParamText via a single-pass char-by-char decoder. This ensures that:

• A real newline in a plain Text param is still encoded as \n (wire) and decoded back to a real newline.
• A backslash in any param value (e.g. from JSON encoding) is encoded as \ on the wire and decoded back to a single backslash, preserving JSON escape sequences intact.

Added regression tests in EncodedSpec and ViewIdSpec covering the exact scenario from the issue report.

Fix #187

[seanhess]

Great work! I tried to fix this quickly last week and got stuck. Thanks for doing this