modify recomon configuration to fix the problematic sequence

The algorithm allen_non_event_data was called in advance of IOVReset algorithm in the sequence. The updated sequence looks like:

LAZY_AND: with_update_and_reset_decision                                                  #=280     Sum=174         Eff=|( 62.14286 +- 2.89861 )%|
 LHCb::IOVReset/LHCb__IOVReset_e2300434                                                   #=280     Sum=280         Eff=|( 100.0000 +- 0.00000 )%|
 Online::UpdateAndReset/UpdateAndReset                                                    #=280     Sum=280         Eff=|( 100.0000 +- 0.00000 )%|
 OdinTypesFilter/OdinTypesFilter_68ba2c6d                                                 #=280     Sum=273         Eff=|( 97.50000 +- 0.933025)%|
 HltRoutingBitsFilter/HltRoutingBitsFilter_17f86f92                                       #=273     Sum=174         Eff=|( 63.73626 +- 2.90970 )%|
 NONLAZY_OR: with_update_and_reset_data                                                   #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
  NONLAZY_OR: with_hlt1_reconstruction                                                    #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
   NONLAZY_OR: allen_non_event_data                                                       #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpBeamline/DeviceBeamline                                                           #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpVPGeometry/DeviceVPGeometry                                                       #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpUTGeometry/DeviceUTGeometry                                                       #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpUTLookupTables/DeviceUTLookupTables                                               #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpCaloGeometry/DeviceCaloGeometry                                                   #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpMagneticField/DeviceMagneticField                                                 #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpFTGeometry/DeviceFTGeometry                                                       #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpMuonGeometry/DeviceMuonGeometry                                                   #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpMuonTable/DeviceMuonTable                                                         #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpRichPDMDBMapping/DeviceRichPDMDBMapping                                           #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    DumpRichCableMapping/DeviceRichCableMapping                                           #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
   LAZY_AND: standalone_global_hlt2_reco_decision                                         #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
    NONLAZY_OR: standalone_global_hlt2_reco_data                                          #=174     Sum=174         Eff=|( 100.0000 +- 0.00000 )%|
   ......

This MR can also solve the problem reported in Moore#914 (closed), but in a quite different way compared to !567 (closed) Please let me know if you are happy with this version of solution. Given that the online operation is approaching, we may try to fix the problem in this week.