Allow users (even anonymous) to cancel signup via secure URL

This would be dependent on getting #341382: Add primary key to signup_log table done and committed. I think both of these should wait until 6.x-1.0 is officially out and I open up a 6.x-2.* branch for new features again. These days, I'm only really in bug-fix mode.

I have a version of a signup_cancel module which implements this. I am fine with the idea of folding its functionality into the main signup module. However, if it does things which are considered undesirable for the main signup module, we will need to figure out how to parse functionality between the two modules.

In response to my client's requests, the signup_cancel module does the following:

1) Support a %cancel_url token which can be included in emails generated by signup. The token is replaced by the output of a tpl file which is passed two pieces of information: a URL for canceling the current signup; a Boolean which indicates whether the minemail module is enabled. This allows replacing the token with different text depending on whether the email will be HTML or plaintext. (As currently written, the token replacement only works well if mimemail handles all email for the system, or is not enabled. This is adequate for my client, but obviously will need some work before it is acceptable for the general community.)

2) When the cancel URL is visited, it triggers cancellation of the correct signup.

3) When a signup is canceled, whether by using a URL or by other means, a record for that signup is copied to a different table before the signup module deletes it from the main table. Currently this saved data is not being used, but the client envisions using it for reports, such as whether some set of users regularly cancel, regularly cancel at the last minute, etc.

In order to implement some of the above functionality, I have made a couple of other changes to the signup module which I have not yet filed as formal feature requests:

a) The ability to capture about-to-be-deleted signups relies on adding a new hook to the signup module which fires right before a signup's record is deleted from the database.

b) The ability to send HTML messages relies on modifying signup so it preserves the HTML version of a message's body in addition to the plaintext version. This allows signup_cancel_mail_alter to use either version as it deems appropriate.

I opened up new the 6.x-2.* new feature series in HEAD and committed #341382: Add primary key to signup_log table to HEAD. So, this is now active again. There's some code I already posted in #341382 related to this which we should fold in here.

The essential things are:

A) The sid/token functions from #341382 to prevent CSRF.

B) The menu path for canceling signups.

C) The %signup_cancel_url email token

The whole question of saving historical signups that have been canceled is really a separate question from this. It's not dependent on the sid field, nor on the ability to have a way for anonymous users to cancel. So, let's talk about it over at #346810: Fix invocation of hook_signup_cancel() so that the record in {signup_log} is still there instead of here.

All the HTML-email stuff should probably be postponed in favor of #290305: Split out email functionality into separate submodule(s) and all the email-related cleanup we're planning over there.

Better title to reflect the real scope of this issue now.

This should do it all:

A) signup_get_token($sid, $operation) and signup_valid_token($token, $sid, $operation) both exist and work.

B) Added a menu path for signup/cancel/%/%. Currently it's protected by 'cancel own signups' permission, not sure if that's the right approach or not. If you give it an invalid token, it just redirects you to the front page with an error message. If you give it a valid token, it presents a confirm form to cancel the signup, then redirects you to the signup node.

C) Added support %cancel_signup_url placeholder for confirmation, reminder, and broadcast emails.

Thoughts on the permission check for signup/cancel/%/% and any of the wording introduced into the UI from this patch?

Added a little warning to the help text to describe that only users with 'cancel own signups' perms can use these links, and committed to HEAD and DRUPAL-6--1. Thanks to deviantintegral for some reviews + feedback via IRC.