Fix the handling of reserved bits in uncommon loads/stores

There's a pattern of load/store instructions that look something like
  * `ldr<variant> <target registers>,
        [<base register>, +/- <offset register>]`
  * `str<variant> <target registers>,
        [<base register>, +/- <offset register>]`

These instructions share a common encoding format, which includes the
presence of 4 reserved bits starting at bit 8 in the instruction word.
These bits should always be zero, according to
`DDI0406C_d_armv7ar_arm.pdf`. However, while this crate did attempt to
validate these bits sometimes, the validation was inverted. Instead of
checking that the bits were zero, the validation would raise an error if
all of the bits were zero! Additionally, some instructions were missing
the check and some instructions that did not use the aforementioned
encoding scheme incorrectly had the check applied to them.

This commit fixes all of the issues I've found along these lines so far.

1 files changed, 1 insertions, 0 deletions

diff --git a/CHANGELOG b/CHANGELOG
index 02c60e5..8229e4d 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -16,6 +16,7 @@ several fixes from @Grond66:
   yaxpeax-arm incorrectly reported a shift of 0, but should have reported 32.
 * ARMv7: reject unconditional instructions with op1=1111xxxx. these were
   decoded as CDP, MCR, or MRC when the bit pattern is actually undefined.
+* ARMv7: fix inverted reserved bit test for some ldr*/str* (immediate) forms.
 
 thank you for the patches!