This avoids a bug when the file is "injected" where the control characters are
potentially intercepted and consumed by the shell on their way to R.

This should fix the original bug reported in emacs-ess#1163, although it doesn't fully
address the issues with MPI support for sessions initiated by
`ess-remote` (which require some additional work as outlined [here](emacs-ess#1163 (comment))

Literal ESC is tricky because it can be consumed by the shell or otherwise
misinterpreted. Use FS to mark the beginning, GS to mark the end, and RS (which
was previously used) to mark the end of the header. Hopefully the separator
control codes are unlikely to cause conflicts.

Also simplify the delimiters to use *solely* the control code and not rely on
other adjacent ASCII characters.

Make corresponding updates to elisp variables
ess-mpi-message-{start,end}-delimiter and update the docstring for
`ess-mpi-handle-messages` (which curiously already used GS as the end
separator).

in `*shell*` buffers, the MPI message we are trying to extract may likely have
the special `read-only` text property, which prevents us from deleting it after
we handle it.

Overcome this by wrapping the deletion command in a let form that binds
`inhibit-read-only` to `t`, as suggested by the elisp manual's "Special
Properties" page

This is necessary to configure the MPI handler to run regularly

As suggested in discussion of emacs-ess#1182, adopt the following protocol for MPI
`SOH header STX payload ETX`

also use octal codes in elisp for better readability

As requested in emacs-ess#1182, rename any variables/functions that I've touched to begin
with `ess--mpi` in order to follow the convention for "internal" features

remove link to ESC sequence documentation (since we no longer use literal ESC
for delimiters) and replace with link to control codes on wikipedia (slightly
redundant with existing link but with more detail).

Update docstring for ess--mpi-handle-messages to
1. Use octal's for literals for better readability on github
2. add a note calling attention to the fact that the message contains literal
ASCII control codes which hopefully gives something search-able if a user is
confused by the seemingly strange characters printed in the docstring

as requested by @vspinu, but for now, leave the mpi delimiter variables names
double-dashed as explicitly requested by @lionel-

new protocol is GS RS head US payload RS GS

See further [discussion on github](emacs-ess#1182 (comment))