feature: add support for simple outbound routing in multi-carrier scenario

[davehorton]

Currently, when an outbound call is placed if the account has access to multiple outbound carriers at either the SP or account level one is randomly chosen to be used. We now want to provide support in the portal for a simple version of "least cost routing" (LCR) wherein a service provider or account can create a simple table of digit patterns where an outbound call will select the carrier associated with the first matching digit pattern.

This feature will require changes to the api-server as well (in progress on the feature/lcr branch in that repo).

A service provider user shall be able to create an "LCR table" in the webapp. This is optional, and if not created then calls will be routed as at present. When a service provider user creates an LCR table it is associated with the service provider, and it may only reference Carriers created at the service provider level (not account level).

Additionally, an account level user shall be able to create an LCR table. This is also optional, if an account level user does not create an LCR table then call routing for that account is governed by the service provider LCR table, if any, and by the current random logic if none exists at either level. When an account level user creates an LCR table it may only refer to Account level Carriers (not service provider level carriers).

Note: The reason for the above restrictions is so that each party -- service provider and account -- has control over their costs.

To create an LCR table requires the following steps:

1. Optionally, give a name to the LCR table.
2. Create a default route (/carrier) to be used if there is no digit match (this is required, so we always have a fallback route)
3. Create one or more routes, each route consisting of the following information:

• a digit match, or regex. If a pattern containing only digits is provided (e.g. 44) then this indicates we will match by seeing if this digit string is a prefix of the called number (e.g., UK in this case). A regex pattern can also be supplied (no need to provide the bracketing "/"s) and in this case the match is evaluated by testing the regex against the dialed number.
• a carrier; this is the carrier to select if a match is found.

Notes:

1. The digit matches have an explicit order to them in the LCR table, and the UI should allow the user to drag and drop rows vertically so as to make them be evaluated sooner or later in the process. The evaluation proceeds from top down as viewed in table.
2. In the initial release, a digit match is associated with a single carrier to use when matched. In future releases, we may allow more complex scenarios, such as "split traffic 50/50 between these two carriers when the dialed number starts with 44", but this is not needed in the initial release. (The database schema does support these more complex scenarios though, in expectation of this future work).