Improve handling of short-lived certificates (#3097) [3.2 backport]

Backport of the short-lived certificate handling from 3.3dev (commit
26a75cf7) to the 3.2 branch, as the issue was reported against 3.2.4.

Certificates with a short validity period (e.g. Let's Encrypt's 6-day
"shortlived" profile, now GA) always tripped the days2warn expiry
thresholds and were shown in red on the "Certificate Validity (UTC)"
line, even seconds after issuance. That red is misleading for a cert
that is intentionally short-lived.

Detect short-lived certificates by their validity period (notAfter -
notBefore) using a new DAYS_VALID_SHORTLIVED threshold (default 10 days,
per the CA/Browser Forum BR 1.6.1 "Short-lived Subscriber Certificate"
definition, which also covers the LE 6-day profile). For such certs:

  - show them as good (not red) with a "short-lived cert (N days)" remark, and
  - warn (HIGH) only when less than 24h of validity is left, and only for
    certificates whose total lifetime exceeds 24h.

Regular certificates are unaffected. The threshold is overridable via the
DAYS_VALID_SHORTLIVED env var (documented in doc/testssl.1.md next to
DAYS2WARN1/2) and added to CHANGELOG.md. The 3.2 man/HTML docs are
Ronn-NG generated, so the entry was added to match that format.

CHANGELOG.md

@@ -7,6 +7,7 @@
 
 ### Features implemented / improvements in 3.2
 
+* Detect short-lived certificates (validity period <= `DAYS_VALID_SHORTLIVED`, default 10 days) and no longer flag them red merely for their short lifespan; warn only when less than 24h is left (#3097)
 * Rating (SSL Labs), as of 3.2.2 version 2009r
 * Extend Server (cipher) preference: always now in wide mode instead of running all ciphers in the end (per default)
 * Remove "negotiated cipher / protocol"