LumiBlockComps: Fix handling of invalid per-BCID lumi data.

There were a number of issues in the handling of invalid per-BCID lumi data
in LuminosityCondAlg.

If we see that the per-BCID luminosity is invalid in
LuminosityCondAlg::updateMuToLumi, then we should give up on trying
to unpack the per-BCID data further.  This matches what LuminosityTool
was doing.

However, the test for whether the per-BCID lumi is valid was copied from
LuminosityTool as:

```
  int perBcidValid = (m_Valid/10) % 10;
```

Keep in mind that for Run 1, m_Valid>>22 is also the preferred channel number;
doing both this _and_ extracting the 10's digit is kind of strange
(think about how you would have to pack that in the first place).
And indeed, if one looks in
<https://twiki.cern.ch/twiki/bin/view/AtlasComputing/CoolOnlineData?redirectedfrom=Atlas.CoolOnlineData>,
it appears that the code that was in LuminosityTool was actually wrong ---
you're supposed to do


```
  int perBcidValid = ((m_Valid & 0x3ff) /10) % 10;
```

which does seem more sensible.  So fix the validity tests like this.

However, we then run into a further problem.   In some data from run 1, the
validity word was 884998144 = 0x34c00000, which is (211 << 22).
So this would have been rejected by the buggy validity test but not
by the fixed one.  However, in this example, BunchLumis does not in fact
contain the channal 211 (only 102 and 201; 211 is in OnlineLumiCalibration).
This was leading to a crash --- so add further protection against this.

See ATLASRECTS-5001.