jdt.ls workspace areas are mutable and written by the server. Putting them
underneath the ycmd installation, even in their own directory makes it
impossible to use a shared installation of ycmd. In order to allow that, we
expose another (hidden) option which moves the workspace root dirdectory
somewhere else, such as the user's home directory.

The 'config' directory is a bit of a misnomer. It is really a working area
for eclipse to store things that eclipse feels entitled to store,
that are not specific to a particular project or workspace.
Importantly, the server writes to this directory, which means that in order
to allow installations of ycmd on readonly filesystems (or shared
installations of ycmd), we have to make it somehow unique at least per user,
and possibly per ycmd instance.

To allow this, we let the client specify the workspace root and we always
put the (mutable) config directory under the workspace root path. The config
directory is simply a writable directory with the config.ini in it.

Note that we must re-copy the config when it changes. Otherwise, eclipse
just won't start. As the file is generated part of the jdt.ls build, we just
always copy and overwrite it.

Move the config directory inside the workspace, and allow the client to
specify a workspace root directory. This means that it is possible to
share the ycmd installation across multiple users by moving the mutable
state directories elsewhere. By default we just move the config dir and
use the old workspace directory.

While we are at it, provide a way to wipe out the re-used workspace.
When use_clean_workspace is False, the workspace can become corrupt, so
we add a command to stop the server, delete the workspace (and
optionally also the config directory), then restart the server.

I have been using this change for years at work and it is very stable. Would like to not maintain it in a fork any longer.

This change is