Handle non-ascii package names in state.format_log

[rallytime]

Fixes #33605

[rallytime]

Don't merge this yet. This bug seems to cover more than just this particular line.

[rallytime]

Ok, I added a simple state test that checks to make sure we can at least get past the state compiler logging when a package name has a non-ascii character in it, which exposed some other places where this would fall down in linux, too.

[rallytime]

Also, @s0undt3ch can you take a look at this one? I know we have the six.u option, and I have used that in the past I believe, but when I was attempting to use that here instead of a plain u prepended to these strings, it wasn't working, while the u does.

[rallytime]

Hrm. Looks like a test is failing. I'll have to take a look.

This also isn't quite the right fix. The original commit is the better fix and not as invasive. I need to write a unit test for this instead and let the other unicode test that is currently failing handle the rest.

[damon-atkins]

You should include "from future import unicode_literals" ready for python 3 Look at reg.py and reg_win_test.py for examples which tests some common unicode chars which occur in windows land. However I not sure how much impact with will have. i.e. how many more modules you will need to add "from future import unicode_literals" too

[cachedout]

We're not quite there on this one. That test isn't passing.

[rallytime]

Ok, this should be fixed up now. I forgot to update the test to the working iteration I was using on my test VM before committing. This has the working version now.