Improve URL routing of web page content versus API routing #146
Description
We need to make 2 semi-related changes to how we route APIs versus the static web page content (documentation, the signup form, etc):
- Remove the need to explicitly white-list the URL prefix paths that get routed to the static web page site. Since we don't have a particularly easy way to update this whitelist, it makes it cumbersome and non-intuitive when you want to add new areas to the website (Adding /developer page #143 is a good example. Also see resolve /community page #89 and Make 404 not found responses consistent #99).
- We can easily achieve this by flipping our whitelist logic around: Since we do know all the URL prefixes for the APIs we're routing to, and those are all managed via the web admin, that should be the whitelist. Then the fallback if it isn't in the list of URL prefixes for known APIs should be the static web page content.
- Allow defining multiple different web page servers to route to based on the domain name. While we support routing APIs based on domain name, we also need to be able to route this other web page content (docs, etc) based on hostname. This becomes more critical to support certain types of hosting arrangements if we want the agencies to be able to keep their own domain (for example, we'll need this to transition developer.nrel.gov over since our API and docs are on one domain, so it's not as simple as aliasing a dedicated hostname for APIs like we've done in in the past. I suspect we'll also need this for some of the other recent agencies we've been talking to for similar reasons).