EPIC: Easier support for producing a custom Java server application

[niloc132]

There are several degrees of freedom we have seen that should be easier to handle without outright forking the project and customizing it. Some examples:

• Start the engine without grpc but still with a script, and halt when finished. (run-and-done scripts for processing data and dumping output or interacting with some other service, etc)
• Support invoking some code directly instead of a script, rather than requiring the script be runtime data.
• Start the grpc server with jetty instead of netty (see #1270).
• Support adding/disabling/replacing grpc services/interceptors.
• Support some other configuration provider, logging, so that the startup code we provide isn't the only way to start.

Most or all of these can be generalized to "Make dagger modules more reusable so custom Java applications can create their own dagger component and start things up their own way". Any gradle project used in this way should be published in whole or in part to maven central for easier reuse, and a few sample apps built to show how this can be used.

[devinrsmith]

Part of this is making the full stack custom, and putting different pieces together. I've had some experience with that here, https://github.com/devinrsmith/crypto-sources, and the experience was "not too hard"

[niloc132]

Agreed, that is important, but deliberately out of scope for this specific ticket (or rather, a different scope, addressing a different set of concerns).

[pete-petey]

Deephaven needs to be embedded in other Java applications... -- Allow Deephaven to call other applications, operating as a framework, not a library. -- Make sample apps that illustrate these capabilities.

[pete-petey]

• Streamline jar distribution (maven central)
• Further make project accessible.
• Document processes for coding vs. building.