Split HAPI service from server

[lindholc]

Ideally the HAPI service will be its own artifact that can be added to a LaTiS 3 instance.

[lindholc]

I've done the split in a branch.

I'm having difficulty figuring out how to get sbt-assembly to produce a single JAR that is the standalone server. I have sbt-revolver and sbt-docker working correctly.

[lindholc]

I believe I have it working, but I'll need to think on it a little bit. It feels wrong. I haven't seen a good example of an SBT build for an application that includes a reusable library.

We may want to move latis.properties from the server project to the service project, because anyone wanting to use the service backed by LaTiS 2 will need that file. (If they want to use processing instructions in TSML.)

[lindholc]

HapiServerApp is now something that clients may wish to pull in (#64).

It exists somewhere between the HAPI service and the HAPI server application:

• The HAPI server application is an standalone, executable thing for end users.
• The HAPI service is useful if you have an http4s application you want to add a HAPI service to, like LaTiS 3.
• HapiServerApp is useful if you want to run your own HAPI server with a different interpreter.

[lindholc]

Perhaps the LaTiS 2 stuff should be in a third module.

[lindholc]

See the http4s build for inspiration. In particular, look at http4sProject, libraryProject, and exampleProject. Perhaps there's a way to hide some of the complexity and duplication this way.

They also use sbt-revolver for a subset of their projects.