Deprecation handling needs to be more sophisticated

[martindholmes]

@sydb discovered that when you try to run a build from the released branch (or from any branch someone might want to use from the past), any deprecations are checked against today's date, which is inappropriate because the deprecation date was not superseded at the time of the release. @sydb and I believe two actions are required to resolve this:

1. The repodate.xml file is generated during the build and shows the date of the last commit to the current branch. Deprecation dates should be checked against this date, not against today's date.
2. Any build should at some point (probably near the end) automatically emit a list of currently-active deprecations, so that these can be easily monitored in the run-up to a release. This could be output into a file, and then cat-ed at the command line so it's part of the log.
3. The instructions for the release process should include a step to check this list and ensure that there are no deprecations floating around the release date which might cause problems during release.

It would also be possible to create a user-controlled parameter supplying the date against which deprecations should be compared, but this is probably not worth the trouble, and would also need to be documented.