i386, i486 and Pentium support

[superfury]

I've added Pentium, i486 and i386 CPU support to the source code.

I've made the 32-bit CR4 extensions and CR0 extensions to not fault on CPUs not supporting them (or the CR4 register).
Also, Pre-PSE CPUs will implement page tables as well (always mapped directly after the executable in physical RAM), at the cost of 4KB per mapped 4MB block.
And of course lowered the used 32-bit instruction set from i686 to i386 for 32-bit 80386/80486/Pentium compatibility.

[superfury]

Also found a little bug with x86_32 using REX prefixes, which obviously don't exist on x86 at all (they're INC/DEC instructions on x86) so fixed those as well.

[superfury]

Improved the search engine a bit and restored prefixes in 32-bit ELFs.

I've also added command line parameters to (using a supplied bitmask number) make it filter out recognised and used(skipped if not used) prefixes. So you can select what opcode groups are CPU-recognised and filter groups from the results for speed (things you're not interested in).

[superfury]

Moved the group LUT into the search engine class as a variable and a class.
This makes the group LUT properly configurable from the settings.
Edit: You might want to squash the commits a bit though, as I've used my repository, changing bits of code outside of Ubuntu (where I'm compiling), inside Windows Visual Studio, then committing to the repository to verify the compiler on Ubuntu (inside a VM) back and forth. And the line endings are incompatible between the two it seems (probably bc of Windows vs Linux line endings). The Windows checkout refuses to compile correctly on the Linux VM. But the Linux checkout (with Linux line endings) compiles without issues.
It seems to run without issues from what I can see. Running a pure i686 CPU, I've given it the command line parameters "2 prefixes, operand/address size, lock/rep/repne prefixes enabled only, so "baresifter_x86_32 prefixes=2 detect_prefixes=15 used_prefixes=13". Not that interested in the segment overrides after all on a simple i686 Pentium Pro CPU. Actually only in the LOCK(because it's required for testing) and 16/32-bit operand/address size prefix results (to determine proper decoding of my emulator).
Edit: Actually, LOCK isn't that required? Leaving out the LOCK prefix from the tests only doesn't cause the #UD fault or locks memory during the instruction execution. It also doesn't affect instruction length.
So basically all you need to verify (on plain 80386-compatible simple CPUs) is the operand and address size overrides (which is what I'm sifting right now, on a Pentium Pro emulated CPU (UniPCemu) without any extended instructions implemented), although using a i686-based floppy SYSLINUX 6.04 (20191223) boot loader on i440fx architecture to load the 32-bit ELF (if I can get that loader to be i386-compatible somehow it would be able to run on any i386, even the one UniPCemu emulates itself on a Compaq Deskpro 386 machine).