Subtract the Age header when computing a cache deadline

[ericmj]

headers_to_cache_deadline/2 computes freshness from max-age alone. RFC 7234 §4.2
defines it as max-age minus the Age header, and Age is what a shared cache reports
about how long it has already been holding the response. Dropping that term means a
document a CDN has held for most of its lifetime is treated as brand new.

That's measurable against a live provider. Two assertions in
oidcc_provider_configuration_SUITE hard-code 3_600_000 for Google's discovery expiry;
with the Age subtraction they come back around 1_751_000, because Google served that
response with roughly 1849 seconds of age. So oidcc reported a document with 30 minutes
of freshness left as having a full hour. As Age approaches max-age the reported
lifetime approaches double the truth. Those two assertions become range checks here,
since the exact number now depends on how long the CDN had the response.

It matters most to oidcc_provider_configuration_worker, which drives erlang:send_after/3
off this value and so schedules its refresh late by whatever the Age was. Callers that
persist the derived timestamp rather than holding it in one process carry the error for
as long as they cache it.

The subtraction alone isn't safe, which is the other half of this change. Before it, the
only route to a small deadline was a provider sending a small max-age, and exactly zero
was impossible because clamp_expiry/2 sends non-positive values to the fallback. After
it, any response a shared cache is serving near the end of its lifetime produces one, and
zero is reachable. The worker hands that straight to erlang:send_after/3 and the backoff
only fires on {error, _}, so it's an immediate refetch with nothing damping it: 6 requests
in 3 seconds against 2. So oidcc_provider_configuration floors the deadline with
max(Deadline, min(?MINIMUM_REFRESH, DefaultExpiry)), one minute. The inner min keeps a
caller that deliberately asked for a shorter fallback_expiry from having it overruled.
Flooring there rather than in the worker is what keeps Expiry :: pos_integer() true in
the loaders' specs instead of widening to admit zero.

no-cache and no-store are deliberately left alone. Honouring them means returning zero,
which is issue #370: kanidm sends no-store, no-cache, max-age=0 on discovery, and commit
31c7f3d fixed the resulting crash by falling back to the caller's expiry. Reversing that
here would reintroduce it, and an RP refetching discovery on every request is not what a
provider misconfiguring its cache headers should get.

headers_to_cache_deadline/2's return widens from pos_integer() to non_neg_integer(),
which is the one part of this that isn't strictly additive. It's the only export in
oidcc_http_util without -doc false, so it's hexdocs-visible by omission rather than by
intent, and both in-tree callers go through oidcc_provider_configuration, which floors
the value before it reaches anyone. Say the word if you'd rather it were hidden.