Cleanup, unify and fix hard-coded signup email tokens

'Name' is just in the default signup form "theme", but it can be customized away by any site. So, sadly, that's not going to work, since this patch is blurring the distinction between the hard-coded values and the customizable stuff. Either:

A) We do what we always do with anonymous users and use their email address instead of their username.

B) We need an advanced setting for what field (if any) from the custom signup form to use for this token for anonymous users, and fall back to the email address if nothing is specified and/or the configured field has no value for a given signup.

C) We treat it sort of like %time => [Untimed] and use [Anonymous] for the token replacement on anon users. This is kinda crappy for usability, but the easiest to code. ;) I'd still lean towards (A) or (B), though.

Ugh, yeah, we need a better solution for this. This came up before over at #135659: %username isn't substituted when broadcasting to anonymous signups and I didn't make a general solution then. Drat. I'm working on this right now ... stay tuned.

I think I've tested everything with this, but another pair of eyes would be welcome. Features:

A) All the hard-coded email tokens are now generated in a single place: _signup_get_email_tokens()

B) This function uses a theme function to decide what to use for the %username token for anonymous users, theme_signup_email_token_anonymous_username() from signup.theme. See the comments there for details.

C) There's also a theme function for what to put in the %info token for the custom signup data: theme_signup_email_token_custom_data().

D) Fixed some translation-related bugs in the hard-coded email template for the signup notification email (aka the "signup forwarding email") while I was touching related code.

I don't think token.module can help with anonymous signups, which is the main thing this issue was originally talking about and what the theme function helps.

I really don't want to rename these something other than "tokens", since that's exactly what they are. So, I fixed some variable names and tried to clarify the comments to be more obvious about the difference between the signup-provided tokens and places that we call out to token.module if it's there.

I found some bugs after a little more testing. There were a few places where I had removed the code that decided what email address to send to (since that's shared logic which now lives in _signup_get_email_tokens()), but the call sites still referred to the old variables that no longer exist, so there was no To: header being set in a few cases. Now, every time we call _signup_get_email_tokens() we also initialize a local $user_email variable based on the %useremail token value we get back, which is what the rest of each call site uses for actually sending the messages. ;)

Any final comments or testing for this before it goes in?

Thanks,
-Derek

Oh, and I should add that while the theme_signup_email_token_anonymous_username() function isn't necessarily the most user-friendly, given the weird theme-based way to customize the signup form, I think that's really the best we can do until we have a viable solution for #29568: Flexible number and type of fields. The only reason you'd need to implement your own version of theme_signup_email_token_anonymous_username() is if you change theme_signup_user_form(), and I added cross-referenced comments about that to both functions in signup.theme. So, I think this is totally reasonable, given the utterly unreasonable way you customize this form in the first place. ;)

Committed to HEAD.

Drat, turns out the code that shipped in 5.x-2.5 was broken due to a variable naming error. See http://drupal.org/cvs?commit=150472 and http://drupal.org/cvs?commit=150471 -- the fix will go out in 5.x-2.6. Whoops. ;)