Jr 6.x 3.3 413 charge dates in the past

**Note: reopening pull request #213**

Two commits, summarized:

Refactoring `fundraiser_extend_future_orders()` to prevent orders from being created in the past, and from being created beyond the expiration date.

`$last_charge_date` is now checked against `time()`, and if it's in the past, `$last_charge_date` is reset to `time()`.

Also, `$new_order_count` was returning the count of all months from `MAX(next_charge)` through now, but was not checking this against the expiration month and year. End result, if the most recent order in the series was 11/2009, but the newly-submitted expiration date is 6/2013, it would create 43 orders starting from now extending into 2016 because the month count from 11/2009 to 6/2013 is 43.

The function has been refactored to instead build a timestamp for the expiration date, and will iterate one month at a time until that expiration date is reached.

Also clarified variable name: `$order_id` is now named `$master_order_id`.

In `fundraiser_billing_update_form_validate()`, making sure that the expiration date is at least next month. It cannot be the current month, as any new orders in series will begin next month.