+ * - $dumpvars initial value declaration (is not an issue if generators
+ * provide sample data for the #0 timestamp, otherwise session data
+ * starts from zero values, and catches up when the signal changes its
+ * state to a supported value)
+ *
+ * Implementor's note: This input module specifically does _not_ use
+ * glib routines where they would hurt performance. Lots of memory
+ * allocations increase execution time not by percents but by huge
+ * factors. This motivated this module's custom code for splitting
+ * words on text lines, and pooling previously allocated buffers.
+ *
+ * TODO (in arbitrary order)
+ * - Map VCD scopes to sigrok channel groups?
+ * - Does libsigrok support nested channel groups? Or is this feature
+ * exclusive to Pulseview?
+ * - Check VCD input to VCD output behaviour. Verify that export and
+ * re-import results in identical data (well, VCD's constraints on
+ * timescale values is known to result in differences).
+ * - Check the minimum timestamp delta in the input data set, suggest
+ * the downsample=N option to users for reduced resource consumption.
+ * Popular VCD file creation utilities love to specify insanely tiny
+ * timescale values in the pico or even femto seconds range. Which
+ * results in huge sample counts after import, and potentially even
+ * terminates the application due to resource exhaustion. This issue
+ * only will vanish when common libsigrok infrastructure no longer
+ * depends on constant rate streams of samples at discrete points
+ * in time. The current input module implementation has code in place
+ * to gather timestamp statistics, but the most appropriate condition
+ * when to notify users is yet to be found.
+ * - Cleanup the implementation.
+ * - Consistent use of the glib API (where appropriate).
+ * - More appropriate variable/function identifiers.
+ * - More robust handling of multi-word input phrases and chunked
+ * input buffers? This implementation assumes that e.g. b[01]+
+ * patterns are complete when they start, and the signal identifier
+ * is available as well. Which may be true assuming that input data
+ * comes in complete text lines.
+ * - See if other input modules have learned lessons that we could
+ * benefit from here as well? Pointless BOM (done), line oriented
+ * processing with EOL variants and with optional last EOL, module
+ * state reset and file re-read (stable channels list), buffered
+ * session feed, synchronized feed for mixed signal sources, digits
+ * or formats support for analog input, single vs double precision,
+ * etc.
+ * - Re-consider logging. Verbosity levels should be acceptable,
+ * but volume is an issue. Drop duplicates, and drop messages from
+ * known good code paths.