There is a horrible morass of include dependencies between hash-map.h, 
mem-stats.h and hash-table.h.  There are even includes in both 
directions (mem-stats.h and hash-map.h include each other, as do 
hash-map.h and hash-table.h.. blech).  Some of those files need parts of 
the other file to compile, and those whole mess is quite awful.  They 
also manage to include vec.h into their little party 3 times as well, 
and it also has some icky #ifdefs.

So I spent some time sorting out the situation, and reduced it down to a 
straight dependency list, rooted by hash-table.h.  There are no double 
direction includes, and no header is included more than once.   Once 
sorted out, I moved the root of this tree into coretypes.h since pretty 
much every file requires everything in the dependency chain.   This 
chain consists of statistics.h, ggc.h, vec.h, hashtab.h, inchash.h, 
mem-stats-traits.h, hash-map-traits.h, mem-stats.h, hash-map.h and 
hash-table.h.

With hash-table.h at the root of the dependency list,  I wondered how 
many files actually need just that.  So I flattened a source tree such 
that coretypes.h included the other required include files, but each .c 
file included hash-table.h.  Then I  tried removing the includes.  It 
turned out that virtually every file needs hash-table.h.  Part of that 
is due to how tightly integrated with mem-stats.h it is (they still need 
each other), and that is used throughout the compiler.  So I think it 
makes sense to put that in coretypes.h.

I also noticed that hash-set.h is included in a lot of places as well.  
Wondering how much it was actually needed, I preformed the same 
flattening exercise and found that only about 10% of the files in gcc 
core didn't need it to compile... the rest all needed it due to 
hash_set<sometype> being in a prototype parameter list or in a structure 
declared in a commonly used header file (function.h, gimple-walk.h, 
tree-core.h, tree.h,...) .  It would be a lot of work to remove this 
dependency (if its  even possible), so I added hash-set.h to coretypes.h 
as well.   rtl.h needed hash-table.h added to the GENERATOR list, but 
not hash-set.. I guess the generators don't use it much :-)

The only other thing of note is the change to vec.h.  It had an ugly set 
of checks to see whether it was being used in a generator file, and if 
not whether GC was available, then included it if it wasn't or provided 
3 prototypes if it wasn't suppose to be included. These allows it to 
compile when GC isn't available (those routines referencing the GC 
functions would never be referred to when GC isnt available).    With my 
other changes, most of those checks weren't necessary.  I also figured 
it was best to simply include those 3 prototypes for ggc_free, 
ggc_round_alloc_size, and ggc_realloc all the time.  When there isn't 
ggc.h, things remain as they are now. If there is a ggc.h included, it 
will provide static confirmation that those prototypes are up-to-date 
and in sync with how ggc.h defines them.

The first patch contains all of those changes.  The second one is fully 
automated and removes all these headers  from every other .c and .h file 
in the compiler.   This also included changes to many of the gen*.c 
routines. I adjusted the #include list for all the *generated* .c files 
to also be up to date with this patchset as well at the previous one 
which moved wide-int and friends into coretypes.h

This bootstraps with all languages enabled  on x86_64-unknown-linux-gnu 
with no new regressions.  It also causes no failures for all the  
targets in config-list.mk.

OK for trunk?

Andrew