Add support for wildcard frontend/backend host handling

[GUI]

When setting up an API backend, we require a single frontend host to listen to and then a single backend host to translate the Host header to. For the developer.nrel.gov migration onto api.data.gov, we had a need for handling wildcard subdomains in both the frontend and backend host (we use this for our staging setup to stage different branches of code on different subdomains). So what this means is that we wanted to be able to route something like *.api.agency.gov (which in turn means foo.api.agency.gov and bar.api.agency.gov) via api.data.gov without having to setup individual API backends for every single subdomain (because we spin up new subdomains frequently on our app server's end).

This was implemented in: NREL/api-umbrella-gatekeeper#13, NREL/api-umbrella-gatekeeper#15, NREL/api-umbrella-gatekeeper@1087d6d, NREL/api-umbrella-web#15, NREL/api-umbrella-web@5f97364, NREL/api-umbrella-web@1f43fe1, and NREL/api-umbrella-router@93327a6

If you can't tell from the hodgepodge of commits, the feature morphed a bit as we worked through some kinks we ran into, so those earlier pull requests don't totally describe where we landed. But it can now be considered stable.

In short, what all this means is that now you can setup a frontend host like *.api.agency.gov that will match any subdomains (but notably not api.agency.gov itself). You can also use the syntax of .api.agency.gov to match both api.agency.gov and *.api.agency.gov. These syntax choices were made to match up with how nginx handle wildcards. In addition, you can also setup a backend with a similar wildcard syntax, and the wildcard portion of matched header will be replaced in the Host header.

As a quick example, if an API backend were setup with a frontend host of *.api.agency.gov and a backend host of .api-backend.com then a request to foo.api.agency.gov would get translated to Host: foo.api-backend.com.

Overall, this wildcard functionality might be a bit of an esoteric feature, so I'm not sure how widely it will be used, but we find it useful, and overall this feature should make the host handling more flexible for any other wildcard use-cases.