Bugfix/composite property namespace and boost

[kwahlin]

Fixes a few things related to libris/definitions#628:

• Score free-text queries against a composite property's combined sub-fields using query_string/cross_fields rather than simple_query_string, to get the best (dis_max-like) match, rather than summing the scores from each field. This avoids scores from e.g. both subject._str and subject.termComponentList._str, which would otherwise always favor complex subjects in the relevancy ranking with the new extended subject: filter.
• Replace Property.getProperty(..), which included hard-coded namespace handling, with a more general Disambiguate.getPropertyByKey(..), which resolves a known property key against an ordered list of namespaces the same way Disambiguate.mapSingleKey(..) already does. This fixes an immediate bug where :subject was incorrectly parsed as ls:subject here, while also adding more flexibility for controlling which namespaces a query's keys should map against and in what preferred order. I think some ambiguity across different namespaces is inevitable (like :subject/ls:subject in this case) and making the namespace precedence configurable (still TODO) and/or overridable per request could be useful when consolidating the old and the new API. If we for example only want to query the "pure" records, we could simply set ['kbv'] as the precedence order, i.e. "map my keys only to kbv terms".

Keeping this as its own PR instead of adding even more to the base branch, since it's closely tied to libris/definitions#628.

[olovy]

LGTM!

Having an additional boolean parameter is a bit unfortunate

[kwahlin]

LGTM!

Having an additional boolean parameter is a bit unfortunate

You're right, better to use the enum instead. Fixed: 44389d2