Introduce license auditing tooling to CI

[workingjubilee]

The pgrx crates have a lot of transitive dependencies. Our total dependency tree is about 246 entries... that's including pgrx itself, last I checked, so the actual number of dependencies we don't personally control is smaller. But not that much smaller. We should be using some tooling like cargo vet or cargo deny to check our licensing requirements in our continuous integration workflows, and probably eventually expand that to soundness concerns (though such an expansion would be low priority, as right now we have to reinforce our own glass house). This would make it easier to handle the massive updates to our dependency tree that we like to do for releases, so that our software depends on the latest versions.

Note that because software licenses treat these cases differently, we may have very different licensing requirements for cargo-pgrx and pgrx: one of these gets linked into binaries (pgrx, the library crate), the other is just a build tool (cargo-pgrx). Although pgrx-pg-sys using pgrx-pg-config in its build.rs may make it look like pgrx-pg-config is in pgrx's directly-linked dependency tree, this is not the case, it is in [build-dependencies] only. This is relevant because we recently had the very silly "oh no, an upstream maintainer is deviously trying to make software developers ship a download link to source code published on crates.io!" scare due to dirs. Making the license for pgrx itself clearer would be another benefit from

• Factor out "build" code from pgrx-pg-config #1451

Any dependents on pgrx may wish to mention what policies they would like to see checked in this issue.

cc @johnrballard re: helping answer this for TCDI.