Limiting and eliminating `unsafe` in user functions about plrust

[thomcc]

We also need to forbid:

• Unsafe attributes like no_mangle, link, link_section, etc (need to look to see if this is a complete list of stable ones). These are unsafe, but do not require the unsafe keyword (although this may change).
• Any extern blocks, as they allow confusing LLVM about the actual signature of functions, and grant access to functions we would like users to not even have the address of. They may become unsafe extern in a future Rust edition, but I've only seen this suggested and not proposed.

[workingjubilee]

One of the inescapable problems in PL/Rust is that even if all the dependencies are very carefully audited and then the function is fully sandboxed by whatever means, the bindings to PostgreSQL themselves must be sound in at least the memory-safe sense and also ideally the logical sense.

As if to answer the call of this issue, several soundness issues materialized in PGX:

• pgcentralfoundation/pgrx#627
• pgcentralfoundation/pgrx#633
• pgcentralfoundation/pgrx#648

I have almost finished redesigning the current "ArrayType handle" that PGX uses to fix some of these issues, starting with a subcomponent that offers much better checks on its soundness properties and more meticulously documented safety conditions. (It will also, amusingly, probably be much faster, not that such is a primary goal.) I hope to return to more... "surface" level concerns like this one very soon.

[workingjubilee]

#95 brings up proc macros as a special concern. Yes, they are. It also will take care of both most concerns regarding PGX and some initial concerns regarding unsafe in user fn, by guaranteeing that any new pgx versions will not insert code with unqualified unsafe. It will not address dependencies or proc macros.

[workingjubilee]

As of #128 we cover a lot of these cases for the main function crate using a significantly modified compilation flow that allows a lot of other shell games that should make auditing functions easier. I'm going to claim victory on this for now and move the remaining concerns to other issues, namely

• #132
• #137
• #138