... using a DirectBlockingConnection, hopefully fixing
Windows deadlocks.

Make locking more fine-grained, move handling of the
No-op message into the WriterThread (basically, do not
lock dataMutex over invocation of the no-op message
as this might queue messages). Introduce a reader thread
using select()/Windows overlapped I/O, removing the need
for timers.

Also introduce mutex into DeviceContext.

Introduce writer thread, fix message & verbose handling.

Reviewed-by: Friedemann Kleint

evaluating a file (which might not exist) is a bit different than just
merging a (possibly empty) map ...

Closer again to qmake, ossi won't like it, but this is exactly what
qmake does, even it it looks a little bit strange. He can come up with
a better fix after he is back from vacation.

Since we can easily do that, just do it. No gurantee that we aren't
going to use rtti in the future.

i think it is finally identical to qmake (i.e., equally braindamaged)

{log,error,file}Message() cannot contain logic which makes the output
conditional on private evaluator state, as they are virtual and thus
derived classes could receive messages which they are not supposed to
receive. so put the logic into likewise named functions in the private
class and call these throughout.

The second and third arguments to qmake's include function are
optional

Task-number: 259398
Reviewed-by: Stian Sandvik Thomassen

the base config is read with a separate reader. we saved its variables,
but not its custom function definitions.

in particular, fix line continuation processing.

also, reintroduce some error handling. it checks only one condition so
far (malformed assignment statement) and is entirely silent, but that's
all that was necessary for internal robustness.

older gcc does not automatically make nested classes of a friend class
friends as well.

QDir::cdUp() is strange ...