strutil: add common parse logic for SR_CONF_PROBE_NAMES input specs

strutil: add common parse logic for SR_CONF_PROBE_NAMES input specs

Add the public sr_parse_probe_names() and sr_free_probe_names() routines
so that device drivers can share a maximum amount of support code. The
input spec can either carry a list of names for individual signals, or
aliases can expand to a set of multiple signals which e.g. correspond
to a protocol or other popular/typical sets of signals. Which increases
usability. Order of items is arbitrary, recursion is not supported (yet
this internal implementation detail may change in a future version).

In the absence of an SR_CONF_PROBE_NAMES value the driver's list of
channel names is returned. Which yields completely backwards compatible
behaviour -- drivers can unconditionally call the parse routine. In the
presence of a configuration value the user spec is taken, aliases get
expanded (alias lookup is case insensitive).

Calling drivers can either have the list capped to a maximum size (pin
count is a natural limit), or get the result of whatever the user has
specified (dynamic size, grows as specs require). The user's probe names
by default get padded with the device's builtin probe names, unless the
spec starts with a '-' (dash), then exclusively the specified signal
names are used.

Calling code which resides in individual device drivers remains minimal.
Behaviour of individual drivers should be identical or very similar from
the user's perspective. The implementation is not tuned for performance,
the logic only executes once during device scan and is not sensitive.

This implementation supports the following aliases for maximum user's
convenience, covering the libsigrokdecode supported protocols with many
signals or with complicated names: ac97 i2c ieee488 jtag jtag-opt lpc
lpc-opt mcs48 microwire sdcard_sd seven_segment spi swd uart usb z80.
The "-opt" variants carry more optional signals which users may want to
inspect sometimes, while often the low logic channel count of typical
devices severely constraints how many signals can get assigned. Let
users pick what they prefer. A mix of a non-opt alias plus a few hand
listed extras is another option.

Adding more aliases is straight forward, and transparently benefts all
participating device drivers.

Outside of isolated inspection of a single protocol (special purpose
traffic recorders), combinations are useful as well to quickly assign
many signals in complex MCU setups which then require fewer adjustment
than full manual configuration:

  $ sigrok-cli -d ...:probe_names=jtag,rtck
  $ sigrok-cli -d ...:probe_names=spi,i2c,uart,r,g,b,clock,data,usb
  $ sigrok-cli -d ...:probe_names=ieee488,uart,led
  $ pulseview -d ...:probe_names=ieee488,uart,led