bpo-31904: Add encoding support for VxWorks RTOS

[pxinwr]

This is the 2nd PR successively after #11968. This PR enables encoding support for VxWorks RTOS. More and full support on modules for VxWorks will continuously be added by the coming PRs.
VxWorks is a product developed and owned by Wind River. For VxWorks introduction or more details, go to https://www.windriver.com/products/vxworks/
Wind River will have a dedicated engineering team to contribute to the support as maintainers.
We already have a working buildbot worker internally, but has not bound to master. We will check the process for the buildbot, then add it.

https://bugs.python.org/issue31904

[vstinner]

Please update the documentation, mention that VxWorks uses UTF-8:

• Include/coreconfig.h: /* Python filesystem encoding and error handler: ...
• Doc/library/sys.rst: "getfilesystemencoding" doc. By the way, can you please also add "* On Android, the encoding is 'utf-8'." and replace "Mac OS X" with "macOS"? Add something like "* On VxWorks, the encoding is 'utf-8'."
• https://docs.python.org/dev/c-api/sys.html#c.Py_EncodeLocale
• https://docs.python.org/dev/c-api/sys.html#c.Py_DecodeLocale
• https://docs.python.org/dev/c-api/unicode.html#c.PyUnicode_EncodeLocale
• https://docs.python.org/dev/c-api/unicode.html#c.PyUnicode_DecodeLocaleAndSize

[pxinwr]

@vstinner
The upstream has changed the location of the file coreconfig.h. This results in conflict. To facilitate the next merging, what is the proper action we need to do? Merging upstream codes down? Or close this PR, rebase my branch, fix the conflict then create a new PR?

[vstinner]

Oh sorry, the conflict is my fault. Thanks for updating the doc. Please keep the same PR. Try to fix the conflict. Use for example "git merge master".

[vstinner]

I'm the middle of a large refactoring work to enhance Python initialization:
https://bugs.python.org/issue36142 Sorry for the issues caused by these changes :-(

[pxinwr]

All right! We will use the same PR to fix the conflict soon.

[vstinner]

I merged your PR, thanks.

It might be interesting to investigate why you have issues with locales on VxWorks, but I know that embedded devices don't really care of locales. Android had similar issues for years. But I'm fine with using UTF-8 on VxWorks.

[pxinwr]

Thanks for the comments associated with locale. Locale support is in our next plan. We will investigate this.

[vstinner]

Thanks for the comments associated with locale. Locale support is in our next plan. We will investigate this.

Every platform has an "incomplete" support for locales. Each implementation makes its own choices: locale name, Unicode version, etc.

I wrote my own Python unit tests for locales, tests very specific to a platform, even for the platform version :-(
https://vstinner.readthedocs.io/unicode.html#test-non-ascii-characters-with-locales

I wrote an article on my recent work on Python code handling locales (bugfixes basically):
https://vstinner.github.io/locale-bugfixes-python3.html

I'm working on that for 10 years, and they are still bugs!