feat: enable wasm optimizations using binaryen

[Stebalien]

This enables both the speed (3) and size (z) optimizations, bringing the miner actor down to 1MiB.

Draft because, while this PR is correct, there's a bug in the FVM filecoin-project/ref-fvm#602.

---

This PR has two main parts:

1. It strips the binary, bringing, e.g., the miner actor down to 1.4MiB (ish).
2. It then uses binaryen to both optimize and further trim down the binary to 1.0MiB.

Motivation:

1. Reduce the block sizes (try to get them down below a megabyte).
2. Reduce the CAR size. With these changes (even without the binaryen optimization step), we can get the compressed CAR size down to about half a megabyte.
3. Optimize the WASM itself for better performance. Parity is doing this with substrate as well.

In terms of how much this helps.... we'll need more thorough testing, but it looks like it helps a bit...

The main downside of this change is that it would:

1. Add an additional compile-time dep on a non-rust project (binaryen).
2. Add a compile-time dependency on cmake (to build binaryen).

I'm happy to drop the binaryen part if we feel that it's too risky, too late. But I'd like to drop the debug info from the release builds so we can get the bundle size down. This would let us check-in the main bundles into the lotus source, significantly simplifying the build process.

[Stebalien]

Let's start with #434. That only reduces the bundle size and doesn't optimize the actors, but it's a good start.

[ZenGround0]

I think running the optimized code with dual execution in a debug bundle (assuming we can get gas/time reports from both) to check on performance improvements and get more confidence for correctness would be an excellent thing to do post M1 launch.

[anorth]

@Stebalien what's the status here? Do we still want to do this?

[Stebalien]

Yes we probably still want it. At a minimum, it reduces binary size a bit.

It may also make things faster (actually, I'm pretty sure it does by optimizing some bulk memory operations), but we haven't merged it because we haven't benchmarked that yet.

Ideally we'd be able to use our conformance test benchmarks, but those don't give us accurate numbers at the moment.

[vyzo]

we should run some gas benchmarks, this is very desirable.

[Stebalien]

@Kubuxu did your benchmark show any benefit?

[Kubuxu]

In my benchmark it saves 0.8%.

[Stebalien]

Ah, I see. I'd still like this change for the _size_ optimizations, but it's significantly less pressing. At least it doesn't slow things down or anything.

[Stebalien]

Yeah, I've done some more benchmarking, and this mostly just makes the build really slow.