This makes a few small tweaks to the en passant machinery that, IMO, make things cleaner.  Notes:

• Instead of using en_passant_top to indicate the maximum allowed value of the range, we use en_passant_end to indicate the open upper bound, i.e., the smallest value that is not part of the range.
• The above change allows the loops to be more idiomatic, with an initial setting (and no +1) and the test using the strict <.  (This ensures that arithmetic overflow can't make those loops infinite.)
• We further shift the assignments into en_passant_multistep_over to one element lower.  (This works because we currently never assign to or read from en_passant_multistep_over[0].)
• The impact of the above is that we can save an element in en_passant_multistep_over without sacrificing working space.

To be honest, I'm still not sure that the dimension of en_passant_multistep_over is correct, that it's large enough to hold everything that it might need to.  I tried to estimate the maximum size of each range in optimisations/hash.h as MAX_EN_PASSANT_TOP_DIFFERENCE (now MAX_NUM_EP_POSSIBILITIES), which I set to nr_rows_on_board - 2.  Naïvely I'd expect en_passant_multistep_over to require dimension up to MAX_EN_PASSANT_TOP_DIFFERENCE * maxply = (nr_rows_on_board - 2) * maxply, but neither the current code nor the code in this PR sets it to that.  I'd appreciate any explanations and/or guidance here.