Remove requirement for passing lat/lngs to APIs

[jonfroehlich]

@misaugstad and I discussed this this week. My proposal, which I think Mikey now agrees with, is to drop the requirement of passing the lat/lng bounding box to all API calls. It's not clear to me when an API user would want only part of our data—and it seems like the only prior argument for forcing the bounding box was due to technical concerns of returning large datasets (which @misaugstad is fairly confident he has resolved).

We can continue to support the lat/lng bounding box REST parameters but by default, I do not think they should be required. If a user doesn't include them, then we return the full dataset.

[misaugstad]

Some further notes on the specifics:

1. Let's keep the examples on the API page including the lat/lngs so that users still have an easy way to get a quick API response to see the structure of the data
2. In the description for each API, there is a section that lists the lat/lng bounds to use to get the full dataset. Let's replace this section with one that has a button to download the full dataset (ofc let's keep the disclaimer that it will take awhile to download).
3. Building on that, instead of a single button, let's have either 3 buttons (or a drop-down) so that users can easily download the full dataset as either GeoJSON, CSV, or a Shapefile!
4. As far as implementation on the back-end goes: when users are getting the full dataset, let's pass in the lat/lng bounds instead of modifying the actual query. By using the lat/lng bounds we have for the city, it will make sure that we aren't including labels from our tutorial street in DC 😁 Plus it means that you don't need to rewrite any SQL. We are getting those lat/lng bounds from the config table.

[misaugstad]

Turns out that (3) is also already a ticket! #3287 I think it makes sense to wrap both of these up into one PR