Re-think project organization

[slominskir]

There are multiple artifacts produced by the smoothness monorepo that aren't allowed to evolve independently and as such a single change in one artifact results in a new version of all artifacts. For example any change to the demo app results in a new version of the weblib. A change in the Dockerfile for the weblib image may not actually effect the lib or demo code, just the Docker environment, but that also results in a new version of all artifacts. More importantly, some apps use the setup bash scripts and Docker image, but do not actually use the smoothness weblib jar artifact. These include the "ATLis" themed apps calendar, workmap, and presenter.

There are good reasons to use a monorepo such as allowing us leverage the Gradle Multi-Project build to take advantage of the artifact dependency feature, such that we can build the library and quickly test it in the demo without having to publish to a maven artifact repo and then download it from the repo (faster build/deploy/test cycle). Though a local maven repo could be a reasonable compromise.

Consider not only separating demo to own repo, but also separating setup scripts into a base/parent project that could then be extended by smoothness weblib and used directly by ATLis themed projects.

[slominskir]

Fixed in v4.0.0 with new jeffersonlab/wildfly Docker image. Some ideas above were not implemented like separating weblib and demo. That can be a new issue later if we decide to go that route.