More finely splitting the compiler and executor for `plrust`

[workingjubilee]

PL/Rust has two distinct functionalities: compiling the code and executing the code. When executing doesn't have the required artifacts available, we could attempt to invoke the compilation side to get that code and thus "lazy-load" functions, but these are otherwise fairly separate events. Splitting these out as far as possible throughout the plrust crate seems desirable, especially if we want to be able to enable remote compilation for clarity's sake if nothing else.

• These may be better off as individual crates, but that might bar certain meshes of functionality.
• We may instead choose to have plrust be a heavily feature-flagged crate with different modules.

[workingjubilee]

There's three major parts of the PL/Rust model, as I see it:

• The compiler
• The dynamic loader
• The PL/Rust functions

Between the first two is what I have also referred to as "the builder".

Between the latter two is what I have also referred to as "the runtime".

[workingjubilee]

PL/Java exists, but works over JDBC, which effectively means that there is a database connection to an active JVM which runs as its own process, achieving the isolation desired but at a higher overhead. Doing something like this may actually be desirable for the builder half of the equation, but probably not for the runtime.