mos65xx: use address on mem operands for relative addressing

[zydeco]

This changes how the mem field is used in relative addressing:

Previously, the last operand would show the offset as it's encoded in the instruction, instead of the address, which doesn't match what is printed:

0x1010:	bpl	$1010
	address mode: relative
	modifies flags: false
	op_count: 1
		operands[0].type: MEM = 0xfe

0x1012:	bbr0	$12, $1012
	address mode: relative bit branch
	modifies flags: false
	op_count: 2
		operands[0].type: MEM = 0x12
		operands[1].type: MEM = 0xfd

Now, it shows the matching address for all operands:

0x1010:	bpl	$1010
	address mode: relative
	modifies flags: false
	op_count: 1
		operands[0].type: MEM = 0x1010

0x1012:	bbr0	$12, $1012
	address mode: relative bit branch
	modifies flags: false
	op_count: 2
		operands[0].type: MEM = 0x12
		operands[1].type: MEM = 0x1012

An alternative to this solution would be using a different operand type (not MEM) for relative addressing, or using a structure to indicate if the address is absolute or relative.

Also, a small fix of setting imm instead of mem, which would return wrong values when running on big endian hosts.

[zydeco]

Looks like the fuzz test is failing due to the fancy quotes in long_desc in bindings/python/setup.py on the v4 branch:
https://github.com/aquynh/capstone/blob/b183f152acd265a5728cfd587e3fd5108ac0f9f8/bindings/python/setup.py#L222

[pranith]

Can you please create a new PR on libcapstone?

[aquynh]

@s-macke please can you ack?

[s-macke]

The first commit fixes one obvious bug.

For the second commit I compared the current output with other architectures. They all use absolute addresses for relative branches. So the commit if fine for me.

Acknowledged

[aquynh]

merged, thanks!