Convert payment methods to plugins

This issue boils down to the fact that the current situation is not ideal. It works, but there are a few possible pitfalls for people who don't fully read or understand the documentation:

1. It's possible to give a PaymentMethod controller data and a controller that don't match, causing execution will fail.
2. It's possible to omit default values for a PaymentMethod's controller data, causing execution to fail.
3. As mentioned before, controllers are instantiated, but only once per page, while they were designed to always do the same thing.

Based on those possibilities, we can write down some requirements:

1. For every payment method, its type of controller and its controller data should have a 'circular dependency', meaning that if the controller type is changed, the controller data automatically needs to reflect the new controller type and vice versa, so those two never get out of sync.
2. The previous requirement is closely related to having a way to easily and surely set default configs for payment methods depending on their controller types.
3. If controllers are instantiated only once, make sure the code reflects that. A solution is to call all controller methods statically. However, some sources say this hurts testing and extensibility. We need to confirm if that is the case with our current setup, where we can easily replace controllers using hook_payment_method_controller_info_alter().
4. In order to make it easier to export or clone a payment method, or change its controller type, we need a consistent and preferably simple way to get its config, so it can be used for a new payment method.

See #1821100: Convert payment method controllers, contexts, statuses and line items to plugins.

Make payment methods be instances of payment method controllers, so we lose a abstraction and add flexibility.

As the next major branch will be for Drupal 8, we can leverage its plugin API:

• Convert payment methods to config entities
• Convert payment method types to plugins. These classes should extend the payment method entity class. This means that controller data properties are now well-documented first class properties of payment methods.
• Convert payment method controllers to payment execution controllers for payment method plugins
• Store payment methods' plugin names in an entity property, possibly as the bundle name.
• Write a custom config storage controller that decides what class to use for payment method entities based on the plugin name that is optionally stored as entity bundle name.

These steps will solve all the issues raised in #1.