arm: Fix bugs with MVE vmov from two GPRs to vector lanes

arm: Fix bugs with MVE vmov from two GPRs to vector lanes

The initial problem I wanted to fix here is that GAS was rejecting MVE
instructions such as:

vmov q3[2], q3[0], r2, r2

with:

Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2'

which is incorrect; such instructions are valid. Note that for moves in
the other direction, e.g.:

vmov r2, r2, q3[2], q3[0]

GAS is correct in rejecting this as it does not make sense to move both
lanes into the same register (the Arm ARM says this is CONSTRAINED
UNPREDICTABLE).

After fixing this issue, I added assembly/disassembly tests for these
vmovs. This revealed several disassembly issues, including incorrectly
marking the moves into vector lanes as UNPREDICTABLE, and disassembling
many of the vmovs as vector loads. These are now fixed.

Regtested on arm-eabi, no regressions.

OK for trunk? What about backports?

Thanks,
Alex

gas/ChangeLog:

	* config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving
	into the same GPR twice.
	* testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message.
	* testsuite/gas/arm/mve-vmov-3.d: New test.
	* testsuite/gas/arm/mve-vmov-3.s: New test.

opcodes/ChangeLog:

	* arm-dis.c (mve_opcodes): Fix disassembly of
	MVE_VMOV2_GP_TO_VEC_LANE when idx == 1.
	(is_mve_encoding_conflict): MVE vector loads should not match
	when P = W = 0.
	(is_mve_unpredictable): It's not unpredictable to use the same
	source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).