View source for Domain-specific measurements and analysis

== Problem ==

Some measurement gear (oscilloscope, specans) have specific measurements and analysis done to their streams by most/all devices. For example any oscilloscope with a display or GUI will support Vpp, rise time, Vmin/max, and so on. Any spectrum analyzer will have peak search, and a few spectrum filters.

If libsigrok supports such measurements as part of its stream or API, this would mean:
* not every frontend needs to write that functionality
* if some piece of hardware does this, libsigrok can just pass it on

== Solution ==
(from [[29c3]])

* should be optional, enabled in the driver
** there needs to be a way to enumerate a list of measurements the driver supports supplying, based on the type of device it supports
** a way to enable them one by one
* the actual functionality should not be in the driver, but rather in a generic way in libsigrok. The session loop should intercept the DF packets and feed them to the various measurement modules, which put measurement/analysis packets on the session bus as needed. Therefore the list should be supplied by the driver in response to a simple info query like SR_DI_HWCAPS and SR_DI_NUM_PROBES. Enabling of these measurements shouldn't touch the driver at all, but rather be intercepted as a libsigrok setting
** however some hardware may support some of these in hardware, in which case the driver DOES need to support it (ask Simon for specifics).
*** libsigrok will know how to interpret some of the enums (e.g. generic Vpp), but not others (e.g. "hardware-based Vpp"). Those it doesn't support will therefore be enabled in the driver, and the driver will send its own measurement packet to the session bus, based on what the hardware provided.
*** something like SR_AN_VPP (libsigrok) and SR_AN_HW_VPP (hardware-based)
* we thus need:
** enum for measurement list (SR_DI_MEASUREMENTS or SR_DI_ANALYSIS?)
** a packet type for analysis
** some enumeration of analysis types (Vpp, risetime, falltime, ...) for use as a field in those packets and enum towards the frontend for the DI, similar to how SR_DF_ANALOG has mq/unit/mqflags fields.

<hr/>
This should be integrated with:

* Factor out libsigrok filter into modular transform system.
** ADC transform, option TTL/CMOS/RS232: transform SR_DF_ANALOG to SR_DF_LOGIC.
** take arguments in the regular thing:key=value format
** integrate current probe compression filter
** resampling module: sample up/down based on factor argument
** noise filter: filter out pulses shorter than the samplerate's period
** software triggering
*** integrate current basic trigger functionality from saleae driver
*** for streaming devices, opportunity for more complex triggers than the hardware can do
*** We will have an extra datafeed type SR_DF_LOGIC_INDEXED, which contains [samplenumber, sample] instead of just raw samples. Samplenumber is a uint64_t, and sample is unchanged (unitsize). Frontends must be able to handle both, and modular filters in libsigrok or the sampling filter in libsigrokdecode may convert from SR_DF_LOGIC to SR_DF_LOGIC_INDEXED at any time.

<hr/>
We will implement both of these as a new modular framework, with an API similar to the new output format API: setup, cleanup, recv. There should also be a way for the module to declare whether it's a filter, i.e. it gets a feed and submits it back possibly altered, or it wants to get a duplicate feed and do its own analysis on it, and possibly submit analysis stuff to the session bus. This is fundamental to what the module does, so can be a static declaration in the registration struct.
TODO:
* name for the modular framework? filter/transform/measurement/analysis