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 last order in the series was 11/2009, but expiration date is 6/2013, it would create orders extending into 2016 because the month count from 11/2009 to 1/2013 was 38.

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, which is less ambiguous.
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.
Adding CHANGELOG.txt entry for pull request 213.
Fixing a bug where the exp year should have been == but it was >=, causing 1/2014, 1/2015, etc. to fail when the current month is January. Only 1/2013 should fail.
In fundraiser_extend_future_orders(), include the form_url value in the fundraiser_recurring table insert. Use the form_url value from the last order.
Manually merging in changes from 6.x-3.3-rc1 to avoid merge conflicts with this branch.
Merge remote-tracking branch 'github/6.x-3.3-rc1' into jr-6.x-3.3-413-charge-dates-in-the-past
Merge pull request #214 from JacksonRiver/jr-6.x-3.3-413-charge-dates-in-the-past

Jr 6.x 3.3 413 charge dates in the past