Refactor CRC32 code

The current design pattern for choosing CRC32 implementations has not scaled well to four architectures (x86, arm64, ppc64le, s390x).

1. The code to choose the implementation at compile time is fragile, and confusing.
2. It is difficult to understand why arm64 maps to X86_HOST since this label does not reflect that it also has a software implementation.

Here is the current list of files:

src/checksum/power8/crc32.S		POWERPC_HOST

src/checksum/power8/crc32_wrapper.c	POWERPC_HOST

src/checksum/x86/checksum.c		X86_HOST

src/checksum/zseries/crc32-s390x.c	ZSERIES_HOST

src/checksum/zseries/crc32le-vx.S	ZSERIES_HOST

One proposal is to refactor based on features + architecture instead of just architecture:

src/checksum/power8/crc32.S		POWERPC_CRC32

src/checksum/power8/crc32_wrapper.c	POWERPC_CRC32

src/checksum/sw/checksum.c		SOFTWARE_CRC32

src/checksum/x86/checksum.c		X86_CRC32

src/checksum/zseries/crc32-s390x.c	ZSERIES_CRC32

src/checksum/zseries/crc32le-vx.S	ZSERIES_CRC32

In this scenario, the newer architectures (ppc64 and s390x) which only use hardware implementations, can continue to only use their respective hardware implementations. ARM64 can simply use the software version. On x86, both X86_CRC32 and SOFTWARE_CRC32 would be enabled since not all x86 machines have SSE 4.1.