Bug in 64-bit parsing of trigger ids

In Run 11, the offline triggerIdCollection was updated to allow for up to 64 different trigger ids.  While the hardware wasn't able to deal with more than 32, "emulated" triggers occuring due to L1, L2, or higher processing were introduced which used the higher bits.

Unfortunately, there was an unsigned vs. signed bug in the parsing.
The bitlist was parsed out of two 32-bit unsigned integers, via the following:

if (mCurrentEvent->runId()> 12000000) {

uint64_t mask = 0;
mask = trigSummary->L1summary[1];
mask <<= 32;
mask += trigSummary->L1summary[0];
trigId[0]->setMask(mask);

mask = trigSummary->L2summary[1];
mask <<= 32;
mask += trigSummary->L2summary[0];
trigId[1]->setMask(mask);

mask = trigSummary->L3summary[1];
mask <<= 32;
mask += trigSummary->L3summary[0];
trigId[2]->setMask(mask);

}

However, the Lxsummary were declared as int's, not unsigned ints.
What this means is that if the 32nd bit was ever set, it would set all
the 32 highest bits of the mask to on, if none of these were supposed
to fire. Worse, the += means that the
set of emulated trigger ids satisfied becomes scrambled if any of the emulated
trigger ids are also satisfied.

So, any data which had the potential to have the 32nd bit satisfied is suspect,
and needs to be reproduced. Below is a summary of the data.
Format is trgsetupname, first run affected, last run affected.

pp500_production_2011_long 12099028 12108020
cuA_production_2012 13159028 13159028
pp200_production_fms_2012 13048054 13068003
pp200_production_2012 13046071 13075024
pp500_production_2013 14084020 14101068
cuAu_production_2012 13132043 13177009
pp500_production_2011 12033087 12098031
pp500_production_2011_long_fms 12099027 12108003
pp500_production_2011_fms 12055039 12098036
cuAu_production_2012_noemc 13144054 13173049
testme 13037138 13037142
testj 13156023 13156024
pp500_production_2011_noeemc 12057006 12104078
pp500_production_2011_long_noeemc 12099055 12107028
pp200_production_2012_setup 13020006 13023014
pp500_production_2013a 14083049 14083050
pp500_production_fms_2013 14095013 14095014
pp500_production_2012 13072028 13090006
Trigger_Config 12049075 12122015
UU_production_2012 13116037 13136015
vernier_scan_2013 14098034 14101078

Bug should have been fixed in dev as of today, Apr. 12, 2013.

Also attach a text file of every issue run. Format is:
trgsetupname run [daqid affected] [triggerid affected] [name of affected trigger id] when [triggerid of 32nd bit] [name of that trigger id]

And a summary of affected triggers by trgsetupname, trigger id name, and trigger id with first run, last run, and number of runs affected.