Restrict UID search query to prefixes, matching displayed ones

[pacien]

Description of the issue:

khard list displays unique prefixes of the UID field,
which is sufficient and convenient to uniquely identify a contact.

However, the search query uid:xxx returns all contacts having "xxx" as a
substring of their UID, not just a prefix.

This makes the displayed UID prefix useless as a unique identifier for
selecting contacts for viewing or editing.

Minimal problematic case:

Consider an address book with two contacts:

• one with "UID: aaabbbb", and
• one with "UID: bbbaaaa".

khard list correctly displays:

• the first with short Uid prefix a, and
• the second with short Uid prefix b.

But khard edit uid:a matches both instead of only the first,
because "a" is a substring of both UIDs!

Workaround:

The full UID can be displayed with --parsable,
which makes it usable in scripts but is bad for humans.

Related issue:

• khard show <uid> - anchor to start of uid ? #136:
  However, the --uid parameter is now deprecated in favour of the new search
  query style uid:something, which is the object of the current issue.

Going further:

I think that working unique short UID prefixes could completely replace the
Index column. Those numeric indexes have the issue of being tied to a
particular context, therefore ephemeral and confusing, while not necessarily
shorter than UID prefixes.

Version info:

• Khard version 0.18.0
• Python 3.10.12
• NixOS 23.05

[lucc]

I like the idea with the prefix match. It is a breaking change which we can not really handle with some transition phase.

At the first glance I also like the idea about using uids as indices everywhere. But that one I imagine to be more controversial so we have to think about it a bit. It feels like there might also come up some good counter examples. Maybe this is worth to introduce a config option.

[lucc]

We also have #240 suggesting to allow multiple contacts to be moved/coped/deleted at once. The idea was to allow index lists and ranges like 1,3, 6-8. This would contradict the idea to use uids as indices (unless we enforce some selector like proposed in #329).

[pacien]

For multiple selections like `1,3`, this is also possible with UIDs. For ranges, I doubt that they are actually that useful since that implies some sort order to be used beyond lucky cases.

[lucc]

The order of the entries should be well defined: for contacts it should be the first/last name as defined in the config file and for address books it is probably the order in which they are given in the config file (but that might just be an implementation detail, I am not sure).

But I assume that multi selection is only interesting for contacts anyways so as long as we have numerical indices ranges might be useful. If we use uids as indices will be very confusing because it is not intuitive (in my opinion) if the alpha-numerical or the display order is intended.