Convert Traffic Ops into a Service Oriented architecture(SOA) product

[srijeet0406]

This PR is not related to any issue.
It adds the ability in Traffic Ops, so that it can be run in conjunction with other backend services, wherein TO would just act as a reverse proxy and forward the requests coming in on the specified paths to the specified backends.

---

Which Traffic Control components are affected by this PR?

• Documentation
• Traffic Ops

What is the best way to verify this PR?

Set up a simple backend service that servers a couple of endpoints (say foo and foos) and run it on a couple of different ports(say, 8444 and 8445). Now, run Traffic Ops with the new config option and make sure that any request to Traffic Ops on the specified endpoints (in the new config) gets forwarded to the backend service. Also make sure that the user sees the response from the backend service.
The new config option should be provided to traffic ops like this:
-backendcfg <File name>
The new config file should look something like this:

{
 "routes": [
   {
     "path": "^/api/4.0/foo/?$",
     "method": "GET",
     "hosts": [
       "localhost:8444"
     ],
     "insecure": true,
     "permissions": [
       "CDN:READ"
     ],
     "routeId": 123456,
     "opts": {
       "alg": "roundrobin"
     }
   },
   {
     "path": "^/api/4.0/foos/?$",
     "method": "GET",
     "hosts": [
       "localhost:8444"
     ],
     "insecure": true,
     "permissions": [
       "CDN:READ"
     ],
     "routeId": 123457,
     "opts": {
       "alg": "roundrobin"
     }
   }
 ]
}

Make sure all the tests pass.

If this is a bugfix, which Traffic Control versions contained the bug?

• master

PR submission checklist

• This PR has tests
• This PR has documentation
• This PR has a CHANGELOG.md entry
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[ocket8888]

I didn't mean to look at anything but the docs, but then I looked at the configuration that it was including, then the related production configuration file that was based on it and wound up glancing at most everything. I'm not looking too hard at any of the logic though - I'm not trying to make a hostile takeover of the review.