Initial support and documentation for cross-compilation

[thomcc]

The only real thing this does aside from docs and CI (which should work, but obviously has only been tested locally), is avoid calling functions from libc, since that was causing significant glibc versioning problems. I did it in a very hacky way.

Doesn't cover:

• Anything other than linux x86_64<->aarch64. Other linux <-> linux is probably supported, but I'd keep them as similar as possible.
• cargo-pgx (see cargo-pgx cross compilation support #981)
• Builds with pgx/cshim enabled (not actually that hard, just only done it once and probably needs a few changes to the build.rs to make things work more intelligently).
• Doing this with Debian is fully documented (because it's easy), doing it with anything else is about half documented (well, more than half, but has a lot of handwaving). Concretely, we should probably tell folks to use Debian for now, although if they have a good setup for cross compilation already, this is probably enough to carry things the rest of the way.

Issues

• The host system's headers are still on the include path when generating bindings, they're behind the ones for the target headers. (note: only an issue on the non-debian path)

  This means if something uses __has_include(<something.h>) to detect support for some header and conditionally include it, and that header is not in $sysroot_dir/usr/include and is in /usr/include and do something conditionally, then it will be included and the logic

  That said, this probably isn't happening -- it takes a fairly specific pattern to happen, and even if it does happen it seems unlikely to impact the generated bindings.

• This uses the headers from postgres configured on an x86_64 machine when compiling postgres. It's unclear to me if to what extent headers themselves vary, e.g. does the code have #ifdef __aarch64__ or #ifdef CONFIG_AARCH64 where CONFIG_AARCH64 comes from a config.h that gets generated by a configure script.

  AFAICT the bindings are essentially the same when cross compiling, so I think it's fine. If it's not, on Debian you'd do something like (if compiling to aarch64)

   sudo dpkg --add-architecture arm64
   sudo apt-get update
   sudo apt-get install postgresql-server-dev:arm64

  Which would install the headers (among other things), and then we'd pass these headers to bindgen. This is annoying, because we can't use the arm64 postgres installation's pg_config when on x86_64, since it's not the right executable for the architecture, but guessing at the header path is probably not that bad.

  But yeah, this didn't seem to be an issue in reality, so I didn't think about how to solve it.

[thomcc]

From @eeeebbbbrrrr in discord, it seems like we may also want ways to configure the direct path to a configured server include dir. I also suspect we'll need ways to completely override the include path for sysroot cases on fedora and the like.

To support these I've some configuration vars to the pgx-pg-sys build script (These aren't yet documented and are only smoke-tested).

• PGX_INCLUDEDIR_SERVER{,_PG<ver>}{,_<target>} can be used to specifies the path to already-configured server include directory (optionally on a per-pgversion and per-target basis -- version takes precedent over target if only one is specified).

  If provided (and not building the cshim), we don't call into the local pg_config (since it may point at one for another architecture). Intended mostly to be used in combination with PGX_PG_CONFIG_PATH, to prevent needing a .pgx/config.toml for cross compiled postgres.

• PGX_BINDGEN_NO_DETECT_INCLUDES{,_<target>} allows disabling bindgen/clang's autodetection of system include paths. This is only useful when also passing --sysroot to a fully configured sysroot (and many other flags) into clang/bindgen somehow (e.g. probably BINDGEN_EXTRA_CLANG_ARGS{,_<target>}). This is mostly in there because I know it will be needed for that case, and there's a good chance we won't need other pgx-pg-sys code changes along with it.

I've also ensured that when you change the various vars that bindgen/libclang/pgx-pg-config understand, we actually rebuild pgx-pg-sys, since this doesn't happen by default, and it was very annoying.

[eeeebbbbrrrr]

I chuckled at sym_blocklist.rs. This looks good tho. Feel free to merge