Allow blocking sending of email notifications

Heres a patch that wraps the call to drupal_mail() in an if statement that checks for the presence of the 'subscriptions_mail_send' variable.

On our production site we force this setting in code:
sites/example.com/settings.php

// Subscriptions:  force sending of emails on production server.
$conf['subscriptions_mail_send'] = 1;

On our staging and development sites, we block this setting in code:
sites/staging.example.com/settings.php
sites/example.local/settings.php

// Subscriptions:  block sending of emails on staging server.
$conf['subscriptions_mail_send'] = 0;

Forgot to update status.

> I already have enough people who come here claiming that "Subscriptions does not send mail" —

I can sympathize with your concern about people having issues with email not working, and I commend you for trying to deal with them, even though those issues often have nothing to do with your module.

> call the variable 'subscriptions_mail_trash_silently' and reverse the logic; default to FALSE

The patch and idea was originally based on functionality in the MailLog module who's email sending paradigm involves a maillog_send variable, which defaults to TRUE, and if you want/need to, you can disable it in settings.php or from the admin settings page. Only difference here is that you can't accidentally modify this in the admin screen and leave it in an "unhealthy" state, without knowing exactly what you are doing; it HAS to be done from code, specifically so that novices dont shoot themselves in the foot ;) Anyway, in the end, making it a killswitch that defaults to OFF instead of a passthrough that defaults to ON, it's 6 and one half dozen.

Will work on a patch this weekend that adjusts to your requests in #3.

>Why not just use Maillog?

This is to prevent notification emails from ever being sent from staging and development servers. If maillog is accidentally left enabled on staging while the client is testing other email functionality, then these subscription notification emails will get sent on every cron run. I want to strongarm specifically this module to prevent it from sending out any updates to real end-users that may be subscribed to specific content types, while the team or client is testing the site.

Fixed wordwrap.

Thanks salvis. cheers.