Launch with argument list to handle text as is

[wasamasa]

Description

tts-mode has a TODO comment about handling punctuation. This PR resolves the comment.

Discussion

The existing code strips all punctuation, then launches a process via shell by specifying a string. This is most likely done for security reasons as punctuation in a commandline string would allow shell control characters and thereby command execution.

This can be avoided by using the list invocation form instead. This PR does so and undoes the string processing as it's no longer needed.

One possible outstanding issue is how the executable customizable is handled. Before the change, a subshell does look up the executable, after the change it's handled directly by the execv equivalent. I'm not sure whether there's a difference in practice, but for cases like "espeak", it doesn't seem to make any.

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

• I have pulled from master before submitting this PR
• There are no merge conflicts.
• I've added the new dependencies as:
  • ASDF dependencies,
  • Git submodules,

    cd /path/to/nyxt/checkout
    git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

  • and Guix dependencies.
• My code follows the style guidelines for Common Lisp code. See:
  • Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
  • Google Common Lisp Style Guide
• I have performed a self-review of my own code.
• My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
• Documentation:
  • All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
  • I have updated the existing documentation to match my changes.
  • I have commented my code in hard-to-understand areas.
  • I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
  • I have added a migration.lisp entry for all compatibility-breaking changes.
  • (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
• Compilation and tests:
  • My changes generate no new warnings.
  • I have added tests that prove my fix is effective or that my feature works. (If possible.)
  • New and existing unit tests pass locally with my changes.

[aartaka]

Merged! Thanks for this elegant solution @wasamasa!