fix(time): catch OverflowError for non-finite floats (#333) - #373

Why is this better than the other 5 or so PRs opened for #333?

Good point. #334 handles naturaldelta, but naturaltime and precisedelta also crash on inf because they go through _date_and_delta:

>>> humanize.naturaltime(float("inf"))
OverflowError: cannot convert float infinity to integer
>>> humanize.precisedelta(float("inf"))
OverflowError: cannot convert float infinity to integer

This PR patches _date_and_delta so all three functions handle non-finite floats.

You're right that catching OverflowError broadly was wrong — it suppressed exceptions for large finite floats like 1e30. I've updated this PR to match #334's check using math.isfinite(), restored the docstring, and added a test for the finite overflow behavior.

If you'd prefer to fold the _date_and_delta fix into #334 instead, I'm also happy to close this one.

Heads-up for maintainers: this PR and #375 fix the same OverflowError-on-non-finite issue (#333) but with opposite semantics for finite too-large values:

• This PR (fix(time): catch OverflowError for non-finite floats (#333) #373): returns the value unchanged only for non-finite inputs (inf/-inf); a finite too-large value still raises the documented OverflowError. The added test test_naturaldelta_too_large_value_raises pins that contract.
• fix: catch OverflowError for non-finite floats in time functions #375: adds OverflowError to the existing except (ValueError, TypeError) catch-alls in naturaldelta/naturaltime, so any oversized value silently becomes str(value) — removing the documented "Raises: OverflowError" contract entirely.

These will behave differently for e.g. naturaldelta(1e20) (finite, exceeds timedelta range): this PR raises, #375 returns "1e+20". Whichever semantics the maintainer prefers, one of the two should be closed as duplicate — flagging early since neither references the other.

(Also noting for completeness that I reviewed #374 separately; unrelated.)