Fix Block policy accounting of lumis

When a run white/blacklist is present, the accounting of lumis is screwed up
and it only reports a number of lumis equal to the number of runs accepted in a block.

Unfortunately, DBS doesn't return block level information on runs and lumis
when calling the listRuns function. So the solution is the following:

- Check first with listRuns and apply run black and whitelist.
- If there is a single run in the block, and the block passed then no need to recalculate lumis.
- However if the block has more than one run, and the list of blocks in the run was affected
  by the run white/blacklist then recalculate the event/file/lumi counts by pulling full file
  information from DBS. This is expensive but we expect the case to be rarely present.

Note that in the dataset splitting it's not necessary to do all this since we can assume safely that a run doesn't cross dataset boundaries.

Tested it with a PromptSkim dataset (the most mixed up run/block distribution we produce :) ), it checks out against my manual calculations from DBS data.

@sfoulkes can you please review it?