Improve guessVocabularyFromURI

[osma]

This is a fix for #868. I had to do a bit of work to fix the problem without introducing additional overhead, so the solution is divided into several parts:

1. Make disambiguateVocabulary (called from within guessVocabularyFromURI) double-check that a URI exists in a vocabulary, even though it is the "preferred" one. This is necessary in some edge cases, e.g. to distinguish between YSO and YSO Places concepts, because the vocabularies have the same URI namespace, but it does introduce an additional SPARQL query to check for a label.
2. To avoid triggering the overhead, in Concept.getProperties(), we first check whether a label for a URI already exists within the graph (the CONSTRUCT query response), and if a label is found, avoid calling guessVocabularyFromURI.
3. Similarly in Model.searchConcepts, when examining the search results, check first if their URIs are within the URI namespace of the current vocabulary (this requires a new method Vocabulary.containsURI) and if it is, skip calling guessVocabularyFromURI.

All in all this PR seems to fix the problem on the concept page while avoiding additional overhead.

While crafting this I also found a way to speed up the search result page a little bit (~10%) by using a whitelist parameter for Concept.getProperties (similar to the one in Concept.getMappingProperties introduced in PR #849), but I'll leave that for another PR.

[osma]

While crafting this I also found a way to speed up the search result page a little bit (~10%) by using a whitelist parameter for Concept.getProperties (similar to the one in Concept.getMappingProperties introduced in PR #849), but I'll leave that for another PR.

This turned out to be problematic, so I won't do a PR now.