Define a recurring withdrawal period in terms of Gregorian calendar months

[TheTaconator]

User Story Recurring withdrawals can currently be defined with respect to any periodic interval greater than the minimum block interval (currently 3 seconds). However those intervals are not necessarily intuitive for many use cases. One example is a desire for a monthly interval. An approximation to a monthly interval might be 30 days; with that approximation and with a starting date-time of January 1, the next period will begin on January 31, and the subsequent period will begin on March 1 or March 2 depending on whether it is a leap year.

@wmbutler indicated that many use cases will need the ability to define intervals in terms of common secular measurements such as "monthly" or "weekly". When defined in terms of Gregorian calendar months, the previous example would be as follows: with a starting date-time of January 1, the next period will begin on February 1, and the subsequent period will begin on March 1.

The definition of the time that the day begins also depends on the time zone of interest. The recommendation here is to permit the definition of the time of the day to be defined with respect to the Greenwich Mean Time (GMT) zone to simplify time calculations and to avoid issues with newly defined time zones that might require hardforks in the blockchain logic. This constraint does permit the flexibility to define what time in GMT does the period begin such as 00:00 GMT or 18:00 GMT. Although this might vary a little in terms of a local time zone over the course of a year, it does enable the creator of a recurring withdrawal definition to approximate a time in their local time zone.

Additional Context (optional) Related to #540

One design question is whether this secular period definitions should enhance the existing withdrawal objects and operations, or should define new objects and operations. The recommendation here is to first attempt enhancing the existing objects and operations.

CORE TEAM TASK LIST

• [ ] Evaluate / Prioritize Feature Request
• [ ] Refine User Stories / Requirements
  • [ ] Draft BSIP
• [ ] Define Test Cases
• [ ] Design / Develop Solution
• [ ] Perform QA/Testing
• [ ] Update Documentation

[abitmore]

Please write a BSIP.

[abitmore]

Note: all withdraw_permission related operations have no extensions field, which means they can't be extended easily. We need to add new operation types if new logic requires additional data fields.