GSMap::haloed_ is slow

[rljacob]

(copied from MCT's old bugzilla)

reported by @worleyph:
"A second performance problem is due to 3 calls to the function
GlobalSegMap_haloed in AVComms of the form ..

if(GlobalSegMap_haloed(GSMap)) then

or

< if(haloed_(pointGSMap)) then (in GSMap::Pelocs

As noted in the comments of the function haloed_, this can be expensive.
It is currently called multiple times for the same global seg. map.
I do not understand the logic or ramifications, but I made the assumption
that whether a GSMap is haloed or not is a characteristic set at
creation time. So, I added a new field to the GlobalSegMap type:

  logical :: haloed                ! Haloed?

and then set this field at the end of initr_, initp_, and initp1_ .
(I don't know what to do about initp0_ .) I got bit-for-bit results
with this one benchmark problem. I do not know if this is the
correct approach and/or correct implementation, but we do NOT want
to be recomputing haloed_ over and over again on the same global seg. map.

This drops the execution time by another 2-3% on 1024 nodes of BG/P."

[rljacob]

(Copied from MCT's old bugzilla)

There's only one call to haloed in AvComms. Its in GSM_gather which is checking
for a fail condition (if the input GSMap is haloed.) The only other calls are in GSMaps::pelocs (also checking for a fail condition) and in
ConvertMaps::GlobalSegMapToGlobalMap