Refactor RuntimeFramework to ensure thread-safety

[ChrisMaddock]

This came up in debugging #168. The inline code comment covers everything, I think.

//RuntimeFramework was originally created for use in
// a single-threaded environment. The introduction of parallel
// execution and especially parallel loading of tests has
// exposed some weaknesses.
//
// Ideally, we should remove all knowledge of the environment
// from RuntimeFramework. An instance of RuntimeFramework does
// not need to know, for example, if it is available on the
// current system. In the present architecture, that's really
// the job of the RuntimeFrameworkService. Other functions
// may actually belong in TestAgency.
//
// All the static properties of RuntimeFrameowork need to be
// examined for thread-safety, particularly CurrentFramework
// and AvailableFrameworks. The latter caused a problem with
// parallel loading, which has been fixed for now through a
// hack added to RuntimeFrameworkService. We may be able to
// move all this functionality to services, eliminating the
// use of public static properties here.

ToDo:

• CurrentFramework
• AvailableFrameworks Interface for GUI dependency
• AvailableFrameworks
• MonoVersion/MonoPrefix/MonoExePath (which relate to available versions of mono, not the mono the current RuntimeFramework object represents)
• GetBestAvailableFramework()

[ChrisMaddock]

(Moving the now deleted comment to a PR, to keep discussion in one place.)

[CharliePoole]

Closing this as obsolete wrt the new codebase. See issue #1168