PCode: fix bug in pcode's SequenceNumber.java

[noobone123]

Hello.
This PR is related to a Potential Comparison Logic Issue in pcode's SequenceNumber.java.

When I try to analyze High PCode (PcodeOpAST) from decompiler using following code

Iterator<PcodeOpAST> opiter = high.getPcodeOps();

I Found PcodeOpAST's order is wrong.
For Example, *(int *)(param_1 + 0x24) has following PcodeOpAST order get from getPcodeOps()

(ram, 0x116e40, 80, 0) => (unique, 0x10000148, 8), INT_ADD, (register, 0x38, 8)[param_1], (const, 0x24, 8)
(ram, 0x116e40, 81, 2) => (unique, 0xc200, 4), LOAD, (const, 0x1b1, 4), (unique, 0x3100, 8)
(ram, 0x116e40, 714, 1) => (unique, 0x3100, 8), CAST, (unique, 0x10000148, 8)

But what we expected is

(ram, 0x116e40, 80, 0) => (unique, 0x10000148, 8), INT_ADD, (register, 0x38, 8)[param_1], (const, 0x24, 8)
(ram, 0x116e40, 714, 1) => (unique, 0x3100, 8), CAST, (unique, 0x10000148, 8)
(ram, 0x116e40, 81, 2) => (unique, 0xc200, 4), LOAD, (const, 0x1b1, 4), (unique, 0x3100, 8)

So finally I found there maybe a issue in SequenceNumber's compareTo method, which can affect the result of
method getPcodeOps().

In the compareTo method, sequence numbers are first compared based on their instruction address pc. If the addresses differ, the comparison result is determined by the outcome of comparing these addresses. If the addresses are the same, then the comparison is based on the values of the uniq field.
However, I think the correct logic is to compare the order field after comparing address pc, so as to ensure the correct order of PCodeAST and not affect the results of subsequent program analysis.