ILocatorFilter issues

There are cases when one instance of ILocatorFilter is used inside Locator instance and also used independently. Example: CppEditor::CppClassesFilter or ClangCodeModel::CppClassesFilter. Note, that both instances of classes are registered also using CppModelManager::setClassesFilter(), so they are freely accessible through CppModelManager::classesFilter() and used outside of Locator:

1. quickfixes.cpp : 1998 - inside matchName() - here machesFor() is called from main thread, so it may concur with the simultaneously running matchFor() in Locator's separate thread.
2. Similar case in ElementTasks::hasClassDefinition() and ElementTasks::openClassDefinition().

The similar case is when ILocatorFilter::allLocatorFilters() is used:

1. Inside CppModelManager::findUnusedFunctions() - here the matchFor() is run in yet another thread, parallel to possibly running matchFor() from Locator object.
2. Inside LineEditField::setupCompletion() - the same remark.

The above scenarios (that matchFor() are used from 2 threads concurrently) are unlikely, however, not impossible.

The possible fix is to:

1. Make it possible to create instances of the same ILocatorFilter subclasse on the fly without registering them on static g_locatorFilters list inside ilocatorfilter.cpp. In this way, when having 2 instances of the same ILocatorFilter subclass, we could run both concurrently.
2. Make ILocatorFilter::allLocatorFilters() private so that filters that belong to Locator object are not publicly shared, so that concurrent run on the same instance isn't possible.
3. Instead of registering a global instance of a filter with CppModelManager::setClassesFilter(), etc... register a method for creating a new instances of locator filter. Leave the lifetime of returned locator filter into caller's responsibility. Move the registration method from CppModelManager into ILocatorFilter (or any other class inside CorePlugin) so that it's easily available for all dependent plugins. Currently, when LineEditField::setupCompletion() from ProjectExplorer plugin tries to fetch "Classes" filter, the CppModelManager::classesFilter() method from CppEditor plugin isn't available because of dependencies in wrong direction.

BTW, class name disambiguation CppEditor::CppClassesFilter vs ClangCodeModel::CppClassesFilter would be really, really helpful when grasping internals. There are more subclasses to be disambiguated.