Ensure correct encoding for hotkeys scripts

[spyoungtech]

Resolves GH-328

Hotkey scripts are generated using tempfile.NamedTemporaryFile, but this currently lacks a specified encoding, which results in the local encoding (i.e. locale.getencoding()) being used, which will likely produce problems.

When the hotstring characters are not valid in the local default encoding, the script generation can fail:

ahk.add_hotstring('тест', 'hello world!')
ahk.start_hotkeys()

Exception in thread Thread-3 (listener):
Traceback (most recent call last):
  File "C:\Python310\lib\threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "C:\Python310\lib\threading.py", line 946, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\Spencer\repos\ahk\ahk\_hotkey.py", line 327, in listener
    f.write(hotkey_script_contents)
  File "C:\Python310\lib\tempfile.py", line 483, in func_wrapper
    return func(*args, **kwargs)
  File "C:\Python310\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 4095-4098: character maps to <undefined>

I suspect that, even if this somehow succeeds because the local encoding is valid (say, CP808 or CP866) , the resulting script will either fail to start or not work as expected because it is explicitly started with the /CP65001 flag, which is likely a mismatch against the local encoding used to write the file.

This problem only affects hotstrings that either use characters that are invalid in the local encoding or when the hotstring characters encoded in the local encoding do not overlap correctly with UTF-8.

It may be possible to register hotstrings similar to how we register hotkeys to make hotstrings more resilient to these kinds of problems, but this change should be made in any case.

[coveralls]

coverage: 77.031%. remained the same
when pulling f106497 on gh-328
into 86d9e56 on main.