[WIP] Lucet i686 (32-bit x86) support... ish

[iximeow]

First, why i686? i386 has, at best, the x87 FPU for floating point operations. I'm pretty sure i686 implies processors recent enough to have MMX/SSE, so our floating point stuff needs fewer changes.

The ABI details of lining things up for guest execution are certainly incorrect. The primary issue at this point is our dependencies though, object believes it can't target I686 and Cranelift is missing some legalizations such as 64-bit divides.

For object, my suspicion is that just adding a few I686 matches to patterns where it matches for I386 should be fine. I've yet to test that though :)

With object not being able to emit i686 objects this hasn't gotten to a point where anything, yknow, runs. 😁

While this is a relatively unserious PR, this is about the same shape I suspect other architectures for POSIX-y OSes would look, so replace i686 with arm32 or aarch64 in your imagination!

[sunfishcode]

Just as a heads up, x87 floating point does not produce the same results as other platforms including SSE in various cases, and the spec testsuite has tests which care about these differences: WebAssembly/spec#124

[iximeow]

This is only present because I was wildly flailing around trying to fix header issues that were caused by fiddling with an include path I shouldn't have. I left it because lucet_types.h references siginfo_t without including signal.h. This isn't an issue because lucet.h includes signal.h before lucet_types.h, but someone using lucet_types.h individually for some reason would be in for a surprise.

... I ought to make this a PR on its own.

[pchickey]

This PR was closed as a byproduct of deleting the branch named master. If this is still an active PR, re-open as a new PR against main.