lib: Add @short_description for all the sections

So gtk-doc doesn't warn about them any more.

libfprint/fpi-assembling.c

@@ -34,6 +34,7 @@
 /**
  * SECTION:fpi-assembling
  * @title: Image frame assembly
+ * @short_description: Image frame assembly helpers
  *
  * Those are the helpers to manipulate capture data from fingerprint readers
  * into a uniform image that can be further processed. This is usually used

libfprint/fpi-async.c

@@ -29,6 +29,7 @@
 /**
  * SECTION:fpi-async
  * @title: Asynchronous operations reporting
+ * @short_description: Asynchronous operations reporting functions
  *
  * Those functions are used by primitive drivers to report back their
  * current status. Most drivers, imaging ones, do not need to use them.

libfprint/fpi-core.c

@@ -33,6 +33,7 @@ GSList *opened_devices = NULL;
 /**
  * SECTION:discovery
  * @title: Device discovery
+ * @short_description: Device discovery functions
  *
  * These functions allow you to scan the system for supported fingerprint
  * scanning hardware. This is your starting point when integrating libfprint
@@ -47,6 +48,7 @@ GSList *opened_devices = NULL;
 /**
  * SECTION:drv
  * @title: Driver operations
+ * @short_description: Driver operation functions
  *
  * Internally, libfprint is abstracted into various drivers to communicate
  * with the different types of supported fingerprint readers. libfprint works
@@ -61,6 +63,7 @@ GSList *opened_devices = NULL;
 /**
  * SECTION:dev
  * @title: Devices operations
+ * @short_description: Device operation functions
  *
  * In order to interact with fingerprint scanners, your software will
  * interface primarily with libfprint's representation of devices, detailed
@@ -114,6 +117,7 @@ GSList *opened_devices = NULL;
 /**
  * SECTION:fpi-core
  * @title: Driver structures
+ * @short_description: Driver structures
  *
  * Driver structures need to be defined inside each driver in
  * order for the core library to know what function to call, and the capabilities
@@ -123,6 +127,7 @@ GSList *opened_devices = NULL;
 /**
  * SECTION:fpi-core-img
  * @title: Image driver structures
+ * @short_description: Image driver structures
  *
  * Image driver structures need to be defined inside each image driver in
  * order for the core library to know what function to call, and the capabilities

libfprint/fpi-data.c

@@ -48,6 +48,7 @@ struct fpi_print_data_item_fp2 {
 /**
  * SECTION: print_data
  * @title: Stored prints
+ * @short_description: Stored prints functions
  *
  * Stored prints are represented by a structure named #fp_print_data.
  * Stored prints are originally obtained from an enrollment function such as
@@ -66,6 +67,7 @@ struct fpi_print_data_item_fp2 {
 /**
  * SECTION: fpi-data
  * @title: Stored prints creation
+ * @short_description: Stored prints creation functions
  *
  * Stored print can be loaded and created by certain drivers which do their own
  * print matching in hardware. Most drivers will not be using those functions.
@@ -582,6 +584,7 @@ API_EXPORTED uint32_t fp_print_data_get_devtype(struct fp_print_data *data)
 /**
  * SECTION:dscv_print
  * @title: Print discovery (deprecated)
+ * @short_description: Print discovery functions
  *
  * The [stored print](libfprint-Stored-prints.html) documentation detailed a simple API
  * for storing per-device prints for a single user, namely

libfprint/fpi-dev-img.c

@@ -28,6 +28,7 @@
 /**
  * SECTION:fpi-dev-img
  * @title: Image device operations
+ * @short_description: Image device operation functions
  *
  * As drivers work through different operations, they need to report back
  * to the core as to their internal state, so errors and successes can be

libfprint/fpi-dev.c

@@ -23,6 +23,7 @@
 /**
  * SECTION:fpi-dev
  * @title: Device operations
+ * @short_description: Device operation functions
  *
  * Those macros and functions will help get access to and from struct #fp_dev,
  * and struct #fp_img_dev types, as well as get and set the instance struct

libfprint/fpi-img.c

@@ -31,6 +31,7 @@
 /**
  * SECTION:img
  * @title: Image operations
+ * @short_description: Image operation functions
  *
  * libfprint offers several ways of retrieving images from imaging devices,
  * one example being the fp_dev_img_capture() function. The functions
@@ -51,6 +52,7 @@
 /**
  * SECTION:fpi-img
  * @title: Driver Image operations
+ * @short_description: Driver image operation functions
  *
  * Those are the driver-specific helpers for #fp_img manipulation. See #fp_img's
  * documentation for more information about data formats, and their uses in

libfprint/fpi-log.h

@@ -23,6 +23,7 @@
 /**
  * SECTION:fpi-log
  * @title: Logging
+ * @short_description: Logging functions
  *
  * Logging in libfprint is handled through GLib's logging system, and behave the same
  * way as in the GLib [Message Output and Debugging Functions](https://developer.gnome.org/glib/stable/glib-Message-Logging.html)

libfprint/fpi-poll.c

@@ -33,6 +33,7 @@
 /**
  * SECTION:events
  * @title: Initialisation and events handling
+ * @short_description: Initialisation and events handling functions
  *
  * These functions are only applicable to users of libfprint's asynchronous
  * API.
@@ -67,6 +68,7 @@
 /**
  * SECTION:fpi-poll
  * @title: Timeouts
+ * @short_description: Timeout handling helpers
  *
  * Helper functions to schedule a function call to be made after a timeout. This
  * is useful to avoid making blocking calls while waiting for hardware to answer

libfprint/fpi-ssm.c

@@ -28,6 +28,7 @@
 /**
  * SECTION:fpi-ssm
  * @title: Sequential state machine
+ * @short_description: State machine helpers
  *
  * Asynchronous driver design encourages some kind of state machine behind it.
  * In most cases, the state machine is entirely linear - you only go to the

libfprint/fpi-usb.c

@@ -23,6 +23,7 @@
 /**
  * SECTION:fpi-usb
  * @title: Helpers for libusb
+ * @short_description: libusb-related helpers
  *
  * A collection of [libusb helpers](http://libusb.sourceforge.net/api-1.0/group__poll.html#details)
  * to make driver development easier. Please refer to the libusb API documentation for more