Next payment date localization efforts

[andrewlimaza]

• ENHANCEMENT: Adjusted the format_subscription_date to be translatable and reworked the logic to support this.

Needs more thorough testing to ensure it's working as is.

Q: Should we ucfirst the returned string in cases like this when the date format is F j,Y, this won't affect any date formats that start with numbers etc.

Example of a fix.

Steps I took to test that it still does what it says:

1. Checkout for a recurring membership level so we have the "Next Payment Date" on the site.
2. You can now test it in a non-English language to ensure translations are working correctly.
3. To ensure local time is returned and not an incorrect time, I set my site time to something like UTC - 7 (GMT and UTC are in the same timezone).
4. Set the format to a custom one like Y-m-d H:i:s (so we can see the actual time).
5. View your membership account page it should show the "Next Payment Date" in local time correctly ( UTC - 7)
6. To test GMT return times, comment out the conditional for "local_time" so it does not return here.
7. Refresh the account page and notice that the dates are different.

[dparker1005]

The key change here in practice is the default settings for the format_subscription_date() function (requesting a timezone in local time) will not return the same value. With the new PR, any request for timestamp will ALWAYS be in GMT/UTC. I don't think this should cause any issues with existing code, but something that is important to note