[LSQ] Add "fallback issue" logic to prepare for approximate address comparison

[MaxWipfli]

This change adds a secondary "fallback issue" path to the LSQ for both loading and storing.
This fallback path runs in parallel to the regular issue path, and guarantees that the oldest pending memory operation (load or store, whichever is older) is issued when possible (i.e., the operands are valid).

While this does not currently change the behavior of the LSQ, this functionality is required as soon as we introduce approximate address comparison (which can cause "false conflicts", where memory operations are deemed unsafe to issue despite having no conflicts).

There are separate flags for fallback load issue and fallback store issue. We do not expect to need the fallback store issue path, as the fallback logic is only required if the approximate address comparison can cause false conflicts even if the set of addresses it considers is empty, which will not be the case for stores. We might need fallback load issue, if we share sets between multiple loads, so the first load could be blocked on a conflict with a later store. (This is not a problem for stores as we can only ever issue one store, so there is no need for sharing sets.)

TODO:

• Thorough testing.
  • with addr_same_pcomp(i,j) = 1,
  • with fallback issue enabled/disabled,
  • with pipeline stages enabled/disabled.

[murphe67]

pretty short review as a first heads up will look properly again later!

Thanks again Max! :)