Add palloc_aligned() to allow arbitrary power of 2 memory alignment

Part of the work that Thomas mentions in [1], regarding Direct I/O,
has certain requirements that pointers must be page-aligned.

I've attached a patch which implements palloc_aligned() and
MemoryContextAllocAligned() which accept an 'alignto' parameter which
must be a power-of-2 value. The memory addresses returned by these
functions will be aligned by the requested alignment.

Primarily, this work is by Andres. I took what he had and cleaned it
up, fixed a few minor bugs then implemented repalloc() and
GetMemoryChunkSpace() functionality.

The way this works is that palloc_aligned() can be called for any of
the existing MemoryContext types.  What we do is perform a normal
allocation request, but we add additional bytes to the size request to
allow the proper alignment of the pointer that we return.  Since we
have no control over the alignment of the return value from the
allocation requests, we must adjust the pointer returned by the
allocation function to align it to the required alignment.

When an operation such as pfree() or repalloc() is performed on a
pointer retuned by palloc_aligned(), we can't go trying to pfree the
aligned pointer as this is not the pointer that was returned by the
allocation function.  To make all this work, another MemoryChunk
struct exists directly before the aligned pointer which has the
MemoryContextMethodID set to MCTX_ALIGNED_REDIRECT_ID.  These
"redirection" MemoryChunks have the "block offset" set to allow the
actual MemoryChunk of the original allocation to be found. We just
subtract the number of bytes stored in the block offset, which is just
the same as how we now find the owning AllocBlock from the MemoryChunk
in aset.c.  Once we do that offset calculation, we can just pfree()
the original chunk.

The 'alignto' is stored in this "redirection" MemoryChunk so that
repalloc() knows what the original alignment request was so that it
the repalloc'd chunk can be aligned by that amount too.

In the attached patch, there are not yet any users of these new 2
functions.  As mentioned above, Thomas is proposing some patches to
implement Direct I/O in [1] which will use these functions. Because I
touched memory contexts last, it likely makes the most sense for me to
work on this portion of the patch.

Comments welcome.

Patch attached.

(I did rip out all the I/O specific portions from Andres' patch which
Thomas proposes as his 0002 patch. Thomas will need to rebase
(sorry)).

David

[1] https://www.postgresql.org/message-id/CA+hUKGK1X532hYqJ_MzFWt0n1zt8trz980D79WbjwnT-yYLZpg@mail.gmail.com