Smarter identifier resolution in conditions involving strings

Smarter identifier resolution in conditions involving strings

Conditions comparing strings behaved rather erratically: while wing=m
was smartly interpreted as wing='m' (because m is ambiguous as plane
selector), wing=e was not so smartly interpreted as wing=effic
(because e unambiguously identifies effic; this was then rejected due
to incompatible types), and wing=g was even less smartly interpreted
as wing=group.

Address this by a redesign of the identifier resolution rules in
nstr_comp(): If the condition contains just one identifier, it names a
selector.  If it contains two, try to intepret either as selector or,
if the other can be interpreted as selector, as value for that.
String selectors accept any identifier as value, numeric selectors
only the ones listed in their table.

Interpret both identifiers as selectors only if their types are
compatible (makes rpath=gu work for ships) and their tables, if any,
match (makes type=spy work for land units).

If more than one interpretation makes sense, drop any value
interpretations of identifiers that are unabbreviated selector names,
and selector interpretations of those that are not (makes wing=w work
for planes).

Change nstr_match_val() to accept any identifier as value for a string
selector.  Replace nstr_mkselval() by nstr_resolve_val(), to resolve
string values in addition to symbolic ones.  Remove resolution to
string from nstr_resolve_id(), drop its last parameter.  Remove unused
nstr_string_ok().  New nstr_is_name_of_ca(), nstr_ca_comparable().

Examples for conditions that are now interpreted differently:

    condition    old interpretation  new interpretation
    wing=g       wing=group          wing='g'
    w=g          wing=group          rejected as ambiguous (1)
    w=e          wing=effic (2)      wing='e'

(1) because both wing='g' and 'w'=group make sense
(2) rejected as incomparable later on