Making sure everything is aligned correctly. Succeeder of #141

[elichai]

Introduction

libsecp256k1 expects thing to be "suitably aligned to hold an object of any type"[0] which is the same jargon C89 uses for malloc:

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated(until the space is explicitly deallocated). [1]

which translated to C11 jargon means "suitably aligned for any fundamental type" :

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). [2]

Which is:

A fundamental alignment is represented by an alignment less than or equal to the greatest alignment supported by the implementation in all contexts, which is equal to alignof(max_align_t). [3]

Rust holds a table of all these alignments for the supported platforms: https://github.com/rust-lang/rust/blob/2c31b45ae878b821975c4ebd94cc1e49f6073fd0/library/std/src/sys_common/alloc.rs
And rust-lang/libc implements max_align_t directly: https://docs.rs/libc/0.2.76/libc/struct.max_align_t.html

So I took the bigger alignment any rust architecture supports and used that as our default alignment, and also added a test that it is bigger than max_align_t (we could also test that in the build.rs if we really want).

Implementation

Use alloc() and dealloc() whenever we allocate, with 16 as alignment.
And use #[repr(align(16))] struct AlignType([u8; 16]) for the preallocated buffer API.

Alternatives

• [Alternative] Making sure everything is aligned correctly #234 - Here the preallocated API is the same, but the regular API uses Vec<AlignType> for allocations.
• [Alternative2] Making sure everything is aligned correctly #235 - Here the regular API is the same, but the preallocated API is made unsafe with s.t. the caller now needs to make sure he upholds the invariants

Closes #138
[0] https://github.com/bitcoin-core/secp256k1/blob/670cdd3f8be25f81472b2d16dcd228b0d24a5c45/include/secp256k1_preallocated.h#L42
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 7.20.3
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf 7.22.3
[3] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf 6.2.8p2

[elichai]

Rebased

[apoelstra]

ack 0638107