use local8bit instead of latin1 resp. 8bit-passthrough, after all.

the situation was as follows:
- if the pro files and file names were all ascii, everything just worked
- if either contained non-ascii:
  - on unix, the evaluator would work as long as the file content
    encoding matched the file name encoding, and the ui would work as
    long as the file name encoding was latin1 (i.e., on no modern
    system)
  - on windows, both would work only if the ansi code page was
    latin1/cp1252 (i.e., on western systems)

i.e., even in the low-level evaluator, only native latin1 systems with
actual latin1 files worked consistently. given this situation, it makes
little sense to make an encoding adapter between the evaluator and the
ui as originally planned. instead, take the easy way out and use
local8bit - this continues to work for native latin1 systems+files in
the backend, and makes the ui work for everything the backend groks and
some more.

Reviewed-by: dt
Task-number: QTCREATORBUG-930