POC: Retrieve the actual alignment of max_align_t

[Kixunil]

The code had a hard-coded maximum alignment of 16 (128 bits) which may have potentially wasted memory and cause memory unsafety if it was ever compiled with larger alignment (unlikely).

This change implements a trick to retrieve the actual alignment from C. To achieve this a newly added C file defines a symbol initialized to _Alignof(max_align_t). It is then compiled (as a separate object), the contents of the symbol is extracted and converted to decimal string which is injected into the AlignedType definition. The definition is generated as a separate .rs file in OUT_DIR and included into types.rs.

This POC currently doesn't support cross-compilation which I intend to fix, I just wanted to show that it's possible to do this. Do we want to?

[apoelstra]

Hah, clever!

Do you think we could just make the C code printf the relevant value, then we run the binary and read it off of stdout? That would be trivially cross-platform (assuming people aren't compiling on embedded platforms) and easy to understand.

[Kixunil]

We can't because the binary would be produced for target (to have the correct max_align_t) and we need to run it at host which would be impossible without an emulator.

[elichai]

Side note, I don't remember what was the reason we decided not to use the libc crate, but it does expose the max_align_t that we can take the sizeof for creating the array.
https://docs.rs/libc/latest/libc/struct.max_align_t.html

[apoelstra]

We stopped using libc because it routinely has 10000-line-diff minor revisions, and given that we only need like, 5 LOC from the entire project, it didn't seem worth the extra trust requirement.

As for this PR, I think it's worth resurrecting. It's pretty simple and I have some experience now doing something similar in rust-simplicity (though what we did there is much less clever; we just export the sizes from C and then use unit tests to check that they're the same as what we hardcoded in Rust -- not sufficient for rust-secp which is a much more mature project and cannot expect anybody to be running the unit tests before using it).

[Kixunil]

We stopped using libc because it routinely has 10000-line-diff minor revisions

That's nothing compared to another reason.

Click here if you want to be pissed off about `libc` even more

They recently silently changed MSRV one-past the upcoming Rust version in Debian stable...

As for this PR, I think it's worth resurrecting.

I'd love to but I don't remember what the issue with cross compilation was. Will have to dig into it.

Also I had an idea that for vendored version we could use the actual alignment of the struct, not the maximum.

[apoelstra]

I don't think there was an actual issue, just that the hardcoded 16 is (at best) inefficient.

[Kixunil]

IIRC for cross compiling we need different binutils and thus convert Rust toolchain name to the GNU one.