Possibly provide an interpreter to isolate blocking jdbc ops into a thread pool

This is a tentative idea inspired heavily by what slick does. In particular, the point would be able to create an interpreter that takes two ExecutionContexts, one for the main thread pool (or whatever thread pool should be given the final results), and one ThreadPoolExecutor, that is better suited for blocking JDBC ops to give the feeling of ✨ asynchrony ✨

This idea might be self defeating in that the overhead of isolation of operations could be large enough that it's faster to leave as-is, but it's definitely worth investigating, particularly for applications such as Http servers wherein work-stealing pools can suffer greatly from hard-blockers like JDBC

Start by reading Slick's linked slick/util/AsyncExecutor.scala and compare its approach with the issue's proposed pair of ExecutionContexts and a ThreadPoolExecutor. Investigate whether isolating blocking JDBC operations provides enough benefit to justify its overhead, and consider the work done when the performance trade-off is established.