Fundraising tech/Payment methods

We inherited a hierarchy of payment methods and submethods from our Ingenico integration, and it has become the convention for all other adapters.

Overhaul 2016

Motivation: This is becoming problematic in a few ways. We care about the donor's intent, which doesn't reliably map to one of our payment methods or submethods. For example, a donor might want to use a PayPal ewallet (usually a method), but not care whether it's through the legacy or express integration. A donor might want to use a credit card, and care which brand (submethod), or they might want to try two and switch between brands. A donor might want to use the real-time bank transfer iDEAL method, and have a specific bank (issuer, or sub-submethod).

This is difficult because a donor ends up with exactly one actual method of payment, but logical grouping necessary, for instance a "pay by credit card" button that leads to card type radio buttons.

We should consider making every concrete variation into its own payment method, in a polyhierarchy if that becomes helpful (e.g. PayPal provided through another gateway). We need to represent donor method intent. We want to query any method for possible siblings or submethods, and have a mechanism to decide whether to show these options or not.

Some adapters have only one top-level method and no variations, so submethod is empty.

Most importantly, methods are supported per country, so we should do an initial thing in GatewayFormChooser to determine available methods at the correct granularity to present to donors.

See the AliExpress payments flow for a great model to follow.