riello (or main?): refactor to `runtimecal` logic and configuration options

[jimklimov]

PR #1692 (for issue #1685) introduced "a localcalculation option to compute battery.runtime and battery.charge if the device provides bogus values", for the riello_usb driver.

This issue aims to track further improvements upon that development:

• there is notable overlap with runtimecal seen in nutdrv_qx and blazer* drivers (and man pages)
  • Note that the runtimecal option requires corner-case values like min/max voltages to be set in further options, which are hard-coded in PR riello_usb.c: option for driver to calculate values of battery.runtime and battery.charge "locally" #1692 (10.9V and 12.9V), see riello_usb.c: option for driver to calculate values of battery.runtime and battery.charge "locally" #1692 comment and sources at https://github.com/networkupstools/nut/pull/1692/files#diff-a4a11d2b3bcd31abd6c677b4e73167428d96ce1ee9190f91c1a074c4a272e2cfR1102-R1109
• expand to riello_ser for consistency
• revise riello* man pages
  • possibly refactor the chapters about "BATTERY CHARGE GUESSTIMATION" into a separate text file included from several man pages (similar to Update USB matching options in man pages #1766 that added and used docs/man/nut_usb_addvars.txt)

UPDATE: Possibly makes sense to generalize this part to all the drivers, via main.c or similar. If the devices do not report their charges and runtimes, users may still want some ballpark values -- and some drivers probably do make and report their guesses, probably in some inconsistent manner across the board. This should probably be pluggable (e.g. research attached to #1027 stressed how different battery chemistries have different non-linear relations of voltage vs. "charge" and remaining runtime under different loads => discharge tempos). See also https://en.wikipedia.org/wiki/Comparison_of_commercial_battery_types

[jimklimov]

CC @aquette @clepple : WDYT about generalizing runtimecal et al for all drivers to have?