component imports: contact matching should not assume default location id

the component imports have a significant flaw when they handle contact matching.

matching can be done by contact id, external id, or the dedupe matching rule.
if using the dedupe matching rule, it uses api/v2/utils.php > civicrm_check_contact_dedupe
(the v3 of this function is the same)

that function first takes the inputted fields and reconstructs them into the required format. it also adds some required values to the array – one of which is the location id – if any location fields are present in the import data.

here's the problem:

the location id is determined by retrieving the system's default location type id. that's a huge assumption that can basically kill contact matching. let's say your default location is Home, but the contacts you are importing to only have Work addresses. none of those addresses are retrieved and used in the matching – and so none of your contacts match. at the very least, we should be comparing against the primary record – regardless of what location type it is.

now that i look at it, it's possible this behavior is true for all imports, not just component imports.
regardless, it's pretty flawed, and will have a big impact on contact matching.