functionally equivalent change to avoid loops in Xcelium simulations

Created by: strichmo

When regressing the interrupt controller changes I had a small handful of simulations hanging to the point where they were not advancing time.

After more testing, I determined that the pr_stall_o signal was triggering alternate always blocks in the controller.

This is technically a stable loop, as the pr_stall_o value always resolves to 1, but the simulator was not smart enough to keep from retriggering the always_comb block.

Based on AppNotes from support.cadence.com this scenario can also be alleviated by avoiding the usage of multiple assignments in one of the always blocks. This PR resolves pr_stall_o's assignment into a single assignment in its always_comb block. There should be no functional change introduced.

I tried to use Xcelium's -delay_trigger switch but that causes a massive simulation performance hit with our mm_ram module.

The change was regressed against 100s of random interrupt tests and the hang is now gone.