Use minijinja templates for emails

[Turbo87]

This PR refactors our email sending code to use minijinja templates instead of format!() and string concatenation. In the long term this even enables us to add dedicated templates for HTML emails too, or use template inheritance to use consistent email footers, etc.

Before:

impl Email for UserConfirmEmail<'_> {
    fn subject(&self) -> String { /* ... */ }
    fn body(&self) -> String { /* ... */ }
}

emails.send(recipient, user_confirm_email).await?;

After (with templates):

let email_message = EmailMessage::from_template("user_confirm", context! {
    user_name => user_name,
    domain => domain,
    token => token.expose_secret()
})?;

emails.send(recipient, email_message).await?;

Hello {{ user_name }}! Welcome to crates.io. Please click the
link below to verify your email address. Thank you!

https://{{ domain }}/confirm/{{ token }}

[Turbo87]

rebased to include the new email type from #11419

[eth3lbert]

A quick glance, and overall LGTM, thanks! I've also left a few nitpicks more related to unified coding style.

[Turbo87]

Thanks for the review! All of the feedback should be addressed now :)

[LawnGnome]

I defer to @eth3lbert's excellent review on the details.

I definitely think that moving to a templating engine is the right call, but I'm not so sure I like the loss of the explicit input fields for each template, both from the perspective of type safety and for knowing what might be interpolated into the e-mails. That said, I don't know that I have a great alternative: the thought of having a proc macro or something to ensure that templates and contexts are in sync feels... terrifying, and well beyond the scope of what we should do here, minijinja doesn't really give us a lot of alternatives, and I don't like any of the minijinja alternatives more than minijinja itself.

So, 👍, but I also think we should remain open to continuing to iterate on the details over time.

[Turbo87]

@LawnGnome yeah, I understand the concern. technically minijinja works with anything that is Serializable and context!() just happens to be one such things. we could also go back to explicit structs, but that still wouldn't solve the problem of the template referring to fields that don't exist. I know there are some template engines that check this at compile time, but IMHO that seems like overkill for this use case.

I guess we can try it out like this and see whether it is sufficient or not. If we see any issues with this approach we can always go back to explicit structs as the template inputs and/or improve our test suite for the templates.