provision gateways as method of data relationships

TLDR;

• Each gateway record names a protocol/interface (handler_machine_name) and refers a medium of exchange to its destination.
• Commerce_Gateway acts as a relationship/networking firewall. Gateway records are created to hold the destination of a payload, or "currency," type.
• Destinations may set their own statuses as they are the ones most apt to know whether they are opened or closed for business, and the ETA time period of status updates. (temporary/permanent).
• Statuses may be changed by other processes when a gateway cannot be reached. (temporary failure; networking issues, destination could not accept request, etc.)

While gateways have typically been designed around payments, that is only one type of gateway. Gateways can be used for all sorts of things:

• Handshakes as gateways to relationships,
• doors as gateways for (figurative and literal) opportunities,
• transportation methods as gateways to move from one place to another,
• purchases as gateways to project completion, including: ingredients for meal preparation, car parts for automotive fixes/upgrades, clothes as entry into specific type of event, and...
• Items into a shopping cart as a gateway for purchase. ("Purchasable?")

In this context, a gateway is a way to prepare for a thoroughfare. Gateways may be considered as a structured process to connect objects within a specific context. With regard to Commerce, gateways _could be_ defined as a structured exchange requiring uniform processes expected by a destination. Gateways do not directly connect records together, but provide an interim processor for contextual relationships.

I submit for consideration and feedback.

This is a work in progress for a design, but it's pretty-well fleshed out. I will be able to help with some pseudocode for test writing to check for failures (and even negative results) to help ensure compatibilities.