[Libreoffice] Master Build Status

I'm able to build master on Mac OS X again. Fredrich's patches caused some fall out.

First off, Fredrich can on line tonight  (my time) and uploaded the last of his patches to upgrade 
Boost from 1.39.0 to 1.44.0. This my have fixed a few issues. I've done the following fixes:

1. We had about 4 locations where the #include <unordered_map> was guarded by INCLUDED_HASH_MAP. 
The issue here was that upordered_map already has it's own internal guards and we still use it to 
guard <hash_map> in about 4 locations. In one case, this was causing a compiler error since the 
guard got defined when hash_map was included and thus unordered_map wasn't. I fixed all locations 
just to be safe.

2. We had some forward declare issues with ::std::vector<>. I just did a #include <vector> in the 
files affected and this fixed the issues. Now that boost has been upgraded, we may be able to 
remove these #includes. I haven't done any research to see if these can be removed.

3. The upgraded boost referenced /boost/range/algorithm/equal.hxx; however, this wasn't delivered 
before. I added the lines to the d.lst file to make sure the range/algorithm directory is delivered.

4. The old hash_map code was doing a two pass process for loading the map in several locations. In 
pass 1, the data was loaded into a temporary <list> in sorted order. In pass 2, they used 
hash_map.resize( list.size ) pre-allocated enough memory to store the entire list and then the 
contents of the list where added to the hash_map. The issue here is that unordered_map doesn't have 
a resize() method so we can no longer do this micro-optimization. In all cases the code was 
modified to just remove the call to resize(). It would be good to have someone go back and find all 
the locations where this two step process is used and  see if we can speedup/simplify the code by 
using a container that will do the sorting for us. The following programs use this pattern (there 
are more out there):

vcl/source/gdi/configsettings.cxx
vcl/unx/headless/svptext.cxx

5. The class T2TypeClassMap was defined twice, once as a unordered_map and once as a hash_map 
(unodevtools/inc/unodevtools/typemanager.hxx); I changed the 2nd definition to an unordered_map.

Overall, Fredrich didn't break too much and I don't think we need to revert any of his work.

Joe P.