Cascade.inl calls interactions with cross sections that are zero, causing warnings

This is highly related to #581 (closed), but can be seen (and probably solved) as a separate issue.

What is the issue?

Running em_showers, I received a decent amount of warnings from PROPOSAL: No stochastic interaction possible for initial energy {} MeV.

Why does this happen?

The reason is the following list of events within the Cascade::step method.

1. At the beginning of the Cascade step, we calculate the total inelastic cross section of all interaction processes total_cx_pre here. The only contribution for EM particles is from PROPOSAL, and we assume that it is positive.
2. The current step is limited by the interaction process, so we know that the particle will stop at the next interaction.
3. We apply continuous energy losses. This means the particles loses energy
4. We recalculate the total cross section total_cx_post here. But the energy has changed, which means that the result of the total cross section is now different. In this case, it is now 0!
5. We call the interaction() method. To sample which of the possible interaction processes should be executed, we sample a random number between 0 and total_cx_post here. But since total_cx_post is 0, the sampled random number is also zero.
6. We call the selectInteraction() method of the process sequence, which will choose the interaction process that will actually be executed, based on the previously sampled random number (which is 0!)
7. Looking at selectInteraction(), the method is designed in such a way that when it gets passed 0, it will automatically select the first interaction process. This is because the selection is based on the condition cx_select <= cx_sum (here). And both numbers are 0, so the condition is true and we will call the first interaction process.
8. proposal::doInteraction() is called, although its cross section for the current energy is zero. Therefore, PROPOSAL rightfully says that it can't perform a stochastic interaction.

Possible fix?

I was able to fix this by just replacing the cx_select <= cx_sum condition with cx_select < cx_sum (note that this needs to be done at two places in the method).

One problem I still see (and which I have already mentioned in #581 (closed)), is that it looks like in the case that doInteraction does not produce any interaction, the initial particle is still erased from the stack. doInteraction does return ProcessReturn::Ok instead of ProcessReturn::Interacted here. This return value causes doInteraction() to print out a debug message here, and also returns the returnCode itself. But this is not caught by the step method here. Therefore, I believe that the particle is still erased here, although it should probably be kept on the stack because it didn't actually interact.