Fix LzxDecoder's handling of odd sized uncompressed blocks if that block is the final one

[Raphtaliyah]

The current implementation of LzxDecoder correctly reads the padding byte to realign the stream to 16 bits in case the uncompressed block is of an odd size.

DiscUtils/Library/DiscUtils.Core/Compression/LzxDecoder.cs

Line 237 in aada925

if ((blockSize & 1) != 0)

However, if that's the last block there is no next block to align it for and even Microsoft's own tool doesn't append that padding byte, causing the read attempt below it to fail for valid blocks.

DiscUtils/Library/DiscUtils.Core/Compression/LzxDecoder.cs

Lines 239 to 242 in aada925

	if (!reader.TryReadRawByte(out _))
	{
	return false;
	}

I couldn't find where it's documented but looking at wimlib's implementation, they only check for that padding byte in case the block wasn't the last one, matching that behaviour.

if (istream.data_bytes_left && (block_size & 1)) {
	istream.data_bytes_left--;
	istream.data++;
}

This PR adds the same fix to the DiscUtils' code which makes it correctly extract the files I encountered this issue with.

[Olof-Lagerkvist]

Well spotted!

Thanks a lot for your contribution!