In general, all std::string or char buffers in CTK are now expected to contain UTF-8 encoded string. This is what was the default on Mac OSX and Linux and it has been made available as an option on Windows from Version 1903 (May 2019 Update). This is where VTK and ITK (and most other software libraries) are moving towards, too.

- use add_executable_utf8 instead of add_executable to make the application use UTF-8 code page on all platforms (already the default on Mac OSX and Linux, but this makes behavior on Windows the same, too)
- use toUtf8 instead of toLatin1 when converting from QString to std::string or char*, especially when converting file names, since now file IO functions expect filenames in UTF-8
- use qPrintable to convert QString to string to be printed on console (std::cout, std::cerr): this converts the string to the local encoding (which is often not be UTF-8 and maybe not Latin1)
- use qUtf8Printable with Qt logging macros (qDebug(), qWarning(), qCritical()) as per Qt documentation
- fixed ctkDICOMAppWidget (there were minor errors, such as signal mismatches)
- use UTF-8 encoding when passing strings to VTK (this is where VTK goes toward https://discourse.vtk.org/t/what-is-state-of-the-art-unicode-file-names-on-windows/1821)

DICOM field content encoding/decoding does not use UTF-8 everywhere (always Latin1 encoding is used when creating DICOM queries or when exporting DICOM items to file, while it could make sense to switch to UTF-8 when values cannot be encoded as Latin1; when exporting files, non-Latin1 characters are stripped for better compatibility with less-advanced file systems).