Add user-facing pages for managing subscriptions

This is great. I may just add one more consideration in that the subscription uuid, Recurly's unique subscription identifier may be worth considering storing locally. As Recurly supports multiple subscriptions. the uuid makes it easier to handle subscription change requests in the case of multiple subscriptions and is pivotal to keep track of a user's subscription when it comes to processing push notifications. Up until very recently, the payment push notifications did not include this uuid which is necessary if you want to act on anything like a failed payment. Currently, the Commerce Recurly stores only account_code, uuid, current_period_started, current_period_ends, created_on FYI.

@quicksketch Yes that's because like many things, the ability to have multiple subscriptions at Recurly was not possible when this module was first written, so the local 'status' column is definitely out, unless you are talking about the state of the account itself, then it's ok. Possible account states are a bit tricky however since an account can be in multiple states. From the docs:

Please note: an account may be in more than one state. For example, an account may be active and have a past-due invoice.

Account states can be active or closed, however an account can be active and past due, meaning Recurly has at least one past-due invoice amongst the account's subscriptions. The subscription in question that has a past due invoice is not easy to get. Calling $account = Recurly_Account::get('1'); I believe will not produce a past_due state only 'active' or 'closed' (although we should double check this!), however a query to $accounts = Recurly_AccountList::getPastDue(); will return accounts with at least one past due invoice. It may be worth putting in a request to Recurly to return an array of states, or at least the failing invoice(s) or subscription uuid(s) when this exists similar to the way they return a pending subscription if it exists. As mentioned, they are as of 2 weeks ago now including the uuid of any subscription when sending a failed payment notification so we know which subscription is failing and don't have to jump through hoops.

I've created two new feature request now, one for the Include an Account page for managing accounts so we can resolve how and if this is even necessary (i.e. a user wants to update their name or email address at Recurly vs. we just use hook_user_update() and whether we show a state on the account itself and store it as "status" locally. The other request is Include a past due status on user-facing subscription page as I feel this is very much needed to bring to the user's attention.