The python module is now pulled in autoload/UltiSnips.vim. This means
that parsing of the .vimrc will only map the keys and set some options -
very cheap.
Unfortunately, the autocommands set up in plugin/UltiSnips.vim pulls in
the python code basically immediately still.
It turns out that vim.eval() will attempt to do Unicode conversion and
can fail when raw bytes are present in the unnamed register. To avoid
this problem, let's not carry the value across the bridge, and instead
store the cached value in Vim directly. This successfully sidesteps the
issue entirely, and provides the correct save and restore behavior.
This also adds a test case for the issue. Since expansion can finish
(despite the errors), the test has to capture the error messages and
examine them for a failure.
It's possible that when using _vim_dec with Python 2 that we fail to
convert the string to Unicode and just return the raw string instead.
This could happen, for instance, when there was arbitrary data in the
unnamed register during the save/restore process. During restoration,
we'd attempt to encode the string, but this may fail with a
UnicodeDecodeError as Python attempts to first convert to Unicode and
then to the requested encoding.
To fix this, let's also catch `UnicodeDecodeError` and return the raw
string if we fail to convert.
