lzms-common.c: Don't process first byte in x86 filter
Microsoft's LZMS compressor and decompressor seemingly skip this byte.
This resulted in different behavior on the following uncompressed data:
0000000 e8 6b e8 fb ff 5e 1f 03 e8 63 e8 fb ff 5e c0 02
0000016 e8 5b e8 fb ff 5e 51 01 e8 53 e8 fb ff 5e c4 00
wimlib would do a translation following the e8 byte at offset 16, since
it would enable x86 translations following the identification of matching
absolute addresses following the potential opcodes at offsets 0 and 8.
But as far as I can tell, the Microsoft implementation just skips byte 0
entirely and doesn't consider it as beginning a potential instruction.