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.