Skeleton of bottom-up FDW

[beargiles]

Skeleton of bottom-up FDW design.

The idea is to fully implement the FDW in the C backend but provide an SPI that can be implemented in java and called via JNI. The java should be completely ignorant of the fact that it's called by a PostgreSQL FDW.

This is the opposite of a top-down design where you try to implement everything in java until you have no choice but to call the backend. This approach has some benefits - but comes at the very high expense of requiring the java code to duplicate a ton of functionality that's already implemented by the back end. That's a lot of extra effort and begging for inconsistent behavior.

The final solution may be somewhere in the middle but if so I hope we can use annotations and automated code generation instead of requiring individual FDW developers to learn backend details.

[beargiles]

I noted elsewhere that I borrowed heavily from the existing UDT but there's a huge difference since a UDT must expose its methods while a FDW should hide them. (It will still need to expose two - but they're only called when the FOREIGN TABLE is created.)

That means that all of the Datum and such in the various FDW classes should be replaced with a conventional java signature. The signature will be equivalent to the C SPI.

That said... DURING DEVELOPMENT it might be useful to expose these methods (plus state) in order to test the implementation outside of the FDW framework. However this would be a stopgap measure and only used until there's no doubt that the 'glue' is working as expected.