Putting support for precompiled headers back in

 Short version: I'm going to push changes that bring back support for PCH. 
Don't let that bother you in any way :).

 Long version:

 Those building with MSVC might have noticed that going from MSVC2008 to 2010 
has a noticeable impact on compile time. I don't remember exactly anymore, 
but #6 tinderbox used to do a full rebuild in like 3-4 hours and now it's 
more than 5 (and a good deal in both of those is make being busy checking 
timestamps, delivering stuff and so on, so the compile time increase itself 
is even worse).

 The argument for PCH (MSVC2010 non-debug build):

$ time make xmloff ENABLE_PCH=
real    4m52.828s
$ time make xmloff ENABLE_PCH=TRUE
real    2m9.293s

 The arguments against PCH seem to be:

- people using non-PCH build breaking PCH build and the other way around - I 
did the bulk of the work actually about half a year ago, and just rebased 
them now. I didn't need to do a single change in any of the few modules using 
PCH, except for removal of includes that no longer work, so it looks that 
it's very unlikely that non-PCH -> PCH would break things. The other way 
around it's probably more likely (forgetting adding needed #includes), but we 
first need those Windows people that'd break the build often enough this way, 
and if we get them, then this is worth it (after all, it's a bit like 
non-debug people breaking the build).

- conflicts between types/#defines - there are a couple of changes needed to 
get things built with PCH, but it's not that many. It seems it's mostly UNO 
vs tools (e.g. Date), and it's quite easy to handle.

- lack of a tinderbox to test it - I intend to switch #6 to use it and see how 
it works in practice

 All in all, it looks to be worth the litle trouble. Also, I modified the PCH 
support a bit to make the extra PCH code very non-intrusive (it's just two 
extra files in inc/pch and one line in the makefile).

 It's considered experimental now, but whoever wants can indeed give it a try 
too (MSVC or Clang are supported).

-- 
 Lubos Lunak
 l.lunak@suse.cz