Check LHCbID ordering in HltSelReportsWriter and sort IDs in Decoder

HltSelReportsWriter implicitly relies on the LHCbIDs being sorted in HltSummaryObjects since std::binary_search is used. I add an explicit check of the order, which emits an ERROR if the condition is not met.

The SelReports data format causes HltSelReportsDecoder to put LHCbIDs in HltSummaryObject potentially unordered. I sort them explicitly.

The discovery of this "feature" was prompted by trying to decode, write and then decode again, as needed by LBHLT-270

As far as I can tell, the HltSelReportsMaker does not enforce order, so we were implicitly relying on it (which should be ok for tracking detectors, at least). We could be a bit more aggressive and call sort, instead of just checking.