Provide ways to clean up old honeypot_time_restriction values

This issue is supposed to provide a way to correct a problem that was fixed as of Honeypot 8.x-1.29, more than 6 years ago.

I do recognize that there MAY be some older systems that were affected by that bug, and MAY have a huge DB table for Honeypot because of that. But, 6 years ... if you haven't noticed it by now, how big a problem can it be?

Regardless, this doesn't affect any sites that were set up with Honeypot 8.x-1.29 or later. It only *potentially* affects sites that were set up with Honeypot 8.x-1.28 and earlier, then upgraded.

At this point, IMO, the best strategy would be to add a check in hook_system_status() to detect an extremely large table size, and provide a link to this issue if an extremely large table size is detected. That gives both a notification to the site admin and a pointer to ways to correct the problem. Perhaps we can provide a stand-alone script as well. But to add a hook_update_N() to do this requires a lot of work and update tests and maintenance for years, and since it's something people will run at most one time, in practice no one is going to write those tests or help test that code. It's just not worth it to make this a semi-permanent part of the Honeypot code base.

Again, no objections to printing a warning (maybe from from hook_requirements()), but I don't plan on working on this because I have no way of testing it (I do not have an old broken Honeypot site). Postponing the issue until someone volunteers to work on it.