Expose each zone's last refresh time via rndc and the stats channel

When a zone is refreshed its file is touched by `named`. Checking the
zone file's modification time is a good way to verify that secondary
refreshes are working correctly. The last refresh time is good for
this purpose since it can give the operator a reasonably prompt
notification that somthing has broken with plenty of time to
remediate, e.g. 24h after a zone stops updating is typically several
days before the zone will break. If you try to alert based on the
expiry time you either need to accommodate different expiry intervals
in different zones (which is duplicating logic that already exists
inside `named`), or set the alert to occur much closer to the time
when a zone will break.

This patch adds the last refresh time alongside the other zone timing
parameters in the output of `rndc zonestatus`, and it adds a similar
selection of zone timing parameters to the statschannel output.

In servers that have a static configuration, `named-checkconf -px` is
a handy way for a script to find out what zones are configured and
where their files are, so that they can be checked for freshness. In a
server with a dynamic configuration (using `rndc addzone` or catalog
zones) the best way to get a list of zones is from the statschannel.
This change gives monitoring scripts a simple one-stop shop for
checking that all zones are reasonably fresh. For example, this script
lists stale zones and when they were last refreshed:

	curl -Ssf http://localhost:8053/json/v1/zones |
	jq -r '.views[].zones[] |
		select(has("lastrefresh") and
			.lastrefresh < (now - 86400 | todate)) |
		"\(.lastrefresh) \(.name)"'
80 jobs for !3075 with u/fanf2/last-refresh in 22 minutes and 31 seconds (queued for 10 seconds)
Name Stage Failure
misc:sid:amd64 Precheck
No job log
💾:sid:amd64 Precheck
No job log
msvc:windows:amd64 Build
No job log
unit:tsan:buster:amd64 Unit
No job log
unit:mutexatomics:sid:amd64 Unit
No job log
system:tsan:buster:amd64 System
No job log