The helper class `horace_paths` should be the only source of paths inside Horace code

[tgperring]

The helper class horace_paths is a quick-fix class whose properties are the locations of key source code locations - for example root_path (the top level Horace path), horace_path and herbert_path (top level source code folders for Horace classes and herbert classes and utilities) etc. There are several issues around it:

• The functionality of Horace is vulnerable to reorganisation of the Horace code base because horace_paths is not used universally throughout Horace. There are several location where the various of the paths returned by horace_paths are constructed directly using fileparts((which(<function_name>))) instead.
• The original implementation of horace_paths used global variables horace_path, herbert_path and root_path, and these global variables still exist and assigned in some functions even where apparently redundant. This is at best confusing, but is potentially a past and still present source of errors.
• horace_paths itself appears to effectively be a constant singleton, but does not follow a standard singleton pattern.

This issue is also entangled with the problem of horace_on and horace_off cleanly uninstalling one version of Horace and installing another. The presence or Horace appears in e.g. process_unit_test_path to be tested by the presence of horace_paths, and it is not obvious that the switch away from using global variables in horace_paths is consistent with such tests - or indeed that it ever was robust!

[abuts]

There is also complex logic to identify configuration path for configurations and make it available for parallel workers who must use the same configuration but may see mounted filesystem differently.

Would be nice to have it in horace_path too with additional set of unit tests to check its validity.
This makes this ticket much more comlex but useful