srd: onewire_link: Cosmetics, simplifications, doc fixes.
srd: onewire_network: Cosmetics, simplifications, doc fixes.
srd: onewire_link/network: Reduce nesting level.

Also, some additional cleanups.
srd: onewire_link/network: Fix annotations, small cleanups.

The annotation types are 'Text' and 'Warnings', not 'Link' etc. as the
annotations of the onewire_link PD (for example) are already clearly
from the link layer. The annotation types should be different things/formats
of a specific PD's annotation output instead (like "Celsius" / "Kelvin"
for some temperature sensor, for example).
srd: onewire_network: Fix typo, command is 0x69.

The 'Overdrive match ROM' command is 0x69, not 0x6d. Verified in various
datasheets and the original 1-Wire/iButton spec.
srd: Rename onewire_transport to maxim_ds28ea00.

It doesn't make sense to have one "generic" onewire_transport PD, as
this layer is very much device-specific and such a generic PD would
have to contain an accumulation of all possible features and commands
and handling code of all existing (now and in the future) 1-Wire
devices, which is neither possible nor useful nor elegant.

There are (for example) 1-Wire thermometers, RTCs, EEPROMs,
special-purpose security chips with passwords/keys, battery monitoring
chips, and many many others. They all have a different set of features,
commands and command codes, RAM areas/sizes/partitioning/contents,
protocols, and so on.

Thus, the layering for 1-Wire PD stacks should look like this:

 onewire_link -> onewire_network -> <specificdevice>

Examples:

 onewire_link -> onewire_network -> maxim_ds28ea00 (special thermometer)
 onewire_link -> onewire_network -> maxim_ds2431 (1kbit EEPROM)
 onewire_link -> onewire_network -> maxim_ds2417 (RTC)
 onewire_link -> onewire_network -> maxim_ds2762 (battery monitor)
 onewire_link -> onewire_network -> maxim_ds1961s (SHA-1 eCash iButton)
 and so on...

So, renaming onewire_transport to maxim_ds28ea00. The non-DS28EA00
specific code will be dropped and/or moved to other PDs on top of
onewire_network later.
srd: maxim_ds28ea00: Fix to only handle DS28EA00.
srd: maxim_ds28ea00: Cosmetics, cleanups.
srd: maxim_ds28ea00: Factor out putx(), small fixes.
srd: onewire_link: Annotations shouldn't be ALLCAPS.

While states in the PD should be ALLCAPS per guidelines (for
consistency), the annotations that a PD outputs (and are shown in a
console via sigrok-cli or in a GUI) should be "normal" human-readable
text/formatting usually, i.e. not ALLCAPS.
sr: chronovu-la8: fix segfault on discovery

If the uninitialized value didn't happen to contain 0, and there
is no Chronovu LA8 connected, the la8_close() causes a segfault
in libftdi.
srd: Initial decoder for AVR ISP protocol.
srd: avr_isp: Factor out part numbers/names to part.py.
srd: avr_isp: Improve Chip Erase handling.
srd: lm75: s/degrees Kelvin/Kelvin/.

The temperature unit is nowadays called just "Kelvin", not
"degrees Kelvin" (even though this was not always the case).
Allow setting samplerate when reading binary files

I had a binary file that I needed to decode using UART decoder. UART
decoder needs to know the sample rate for the data, but currently it's
not possible to pass parameters to input formats and so the "binary"
file format always sets the samplerate to 0.

This patch adds the possibility to append a colon-separated list of
key=value options to the -I argument, in the same way -d supports it.
Also, it makes the "binary" format support the "samplerate" option.

I included the GHashTable containing input format options directly in
the sr_input struct. I'm not sure if that's the right way to do it. I
saw that -d uses a much more elaborate system with device capabilities
and typed options, but that seemed like an overkill for input formats.
sr: fix struct sr_input for parameter passing
sr: extra checks for properly handling driverless devices
sr: always use uint64_t for samplerate
onewire: fixed a ROM command code typo