Hoist language-finding in expand_symtabs_matching

Hoist language-finding in expand_symtabs_matching

Right now, cooked_index_functions::expand_symtabs_matching computes
the language for each component of a split name, using the language of
the corresponding entry.

Instead, I think that we want to do all the comparisons using the
final entry's language.  I don't think there's a way to trigger bad
behavior here right now, but with another series I'm working on, we
end up with some entries whose language can't reliably be determined;
and in this case using the final entry's language avoids issues.

I suspect we could also dispense with the per-segment name-matcher
lookup as well.