interrupts interrupted demonstrates bug in IRET

[William "Amos" Confer]

When an interrupt is interrupted, IRET followed by m_interrupts_handle_interrupts() causes the first of the instructions that should complete after the return to be lost.

[William "Amos" Confer]

Add PC to pipeline latches to accurately follow Write-Back sequence of instructions.

Updated the ints_high_low test to more accurately demonstrate what is happenning in a recent issue (see #16). This commit further modifies the interrupt handler to address problems related to this issue by ensuring the high and low IRRs have at most only one set bit between the pair. However, this doesn't solve the problem entirely. The modified test shows that all the final flags (whenever r5 is changed) occurs and in the expected order. The 5th flag however is skipped entirely.

The expected WB PC sequence is (by hex address [NULL is a bubble]): 0x0000 0x0000 0x0000 0x2000 0x0000 0x2002 0x2004 0x0000 0x2006 0x2008 0x0000 0x200A 0X200C 0X200E 0X0000 0X2010 0X2012 0X2014 0X0000 0X2016 0X0000 0X0000 0X0000 0X2022 0X2024 0X0000 0X2026 0X0000 0X0000 0X0000 0X2032 0X2034 0X2028 0X202A 0X0000 0X0000 0X0000 0X2018 0X201A...this begins an infinite loop to 0x201A

The actual sequence differs from this just before the infinite loop. The instruction immediately following the first generated interrupt is skipped entirely. So the current incorrect sequence ends: 0x2028 0x202A 0X0000 0X0000 0X0000 0X201A

→ <<cset 5ab59c62233c>>

[William "Amos" Confer]

fix issue #16

→ <<cset ac20a87c2760>>