Protect the workarea of the server for different launch scenarios

[tjwatson]

See #7448 for failing scenario

If the installUtility is used against a server configuration then it will use the persistent workarea of the server and potentially trash some of the cached data in it. For the failing issue above the persisted configuration Dictionary data was being deleted by running the installUtility against the server configuration (perhaps another bug to fix?).

In the past there have been other cases where this behavior of sharing the workarea store for the different launch scenarios has caused us issues (Alasdair to inject cases he knows about here). I can think of the following ways to address this:

1. Fix all cases to avoid trashing the workarea persistent data, for example, don't cause the persistent configuration Dictionary data files to be deleted as a side effect of running installUtility
2. Partition the workarea for different launch scenarios. For example, the runtime would have a subfolder workarea/runtime, the installUtility could have workarea/install, minify/package server would have workarea/package etc.
3. Have everything that uses the server workarea/ folder besides the actual runtime to invalidate the cache causing an implicit --clean, similar to how the fingerprint file is used for installing iFixes.

[NottyCode]

We should do #2 as the safest option. The default location for a workarea must not be the location the server runs from.