input/vcd: suggest downsampling to users for reduced resource consumption

input/vcd: suggest downsampling to users for reduced resource consumption

Naive creation of VCD files with inappropriately fine timescale specs
results in excessive resource consumption due to libsigrok's assumption
of a constant rate stream of sample data. A workaround is available and
documented, but users need to become much more aware.

Implement a reliable check for wasteful input data situations which
depends on the reception of _all_ input data, and can only alert users
late after potentially spending lots of time and assuming that available
resources allow completion of the import. Users could miss that check's
outcome.

Also implement early checks which (necessarily) are based on weaker
conditions, to already raise user's awareness while data import still is
executing. Phrase these early checks as computationally inexpensive as
possible, to not affect the main task of data import too much. Avoid
false positives by balancing the desire for early emission of messages
and picking appropriate conditions to test for.

This commit implements the foundation for early estimates and reliable
terminal checks, as well as the emission of messages which support users
and allow a more effective use of the file format. The specific limits
and tested conditions still may benefit from more tuning in the future.

The input module logic in this commit emits an information for harmless
cases, and emits warnings for "severe" cases where default option values
or incomplete user specs result in several orders of magnitude higher
resource consumption than necessary. GUI users may not notice, but the
library cannot help that given the current infrastructure -- the library
stricly does as the application tells it to, according to user input.

The best use is to run the CLI's --show feature on VCD files of unknown
content, to get an idea how to most appropriately configure a subsequent
file import. An alternative is to open the VCD file before import, check
the timescale in the header and the last two timestamps, to get an rough
estimate of a useful downsample factor.

This is motivated by but does not resolve bug 1624.