prevent overflows in config_parseduration and config_parsebytesize

[elliefm]

These two functions parse numbers from strings, and don't presently have any overflow protection. They're only used for parsing values from imapd.conf, so this hasn't been an issue -- the administrator can just choose not to use values that will break.

cyr_expire reads some of its behaviours from mailbox annotations, and #4533 extends it to support "duration" values for some of these annotations, using config_parseduration as its parser. I don't think I would expect users to have permissions to set these annotations, but if somehow they can, then config_parseduration might be processing user-supplied input, and ought to be protected against overflow just in case.

This PR adds overflow protection to config_parseduration, and also to config_parsebytesize for completion's sake. I also tightened up config_parseduration's parsing of bogus negative values.

@rsto previously made a version of this as #4534. I borrowed and extended his tests.

[elliefm]

It turned out config_parsebytesize already used strtoll for the numeric part of the parsing, and it does so because bytesizes only permit a single numeric section with a single suffix anyway (like "1MB" but not "1MB23KB"). And use of strtoll meant it already had overflow detection for the numeric section, but it still needed overflow protection for the suffix multipliers, which I've added.

I've kept the config_parseduration implementation basically the same as it was, rather than converting it to use strtowhatever, because once you factor in the complexity of needing to parse multiple numeric sequences, the byte-by-byte parser is easier to read than a strtowhatever loop.

[rsto]

LGTM