Change to more SQL-like interface

[jterry64]

We've discussed the idea of the API actually just accepting a SQL statement to make it consistent with other APIs. As I'm testing it on a different widget scenarios, I think we might need something more like that to support all scenarios.

For example, one of the widgets just ranks certain areas by the amount of relative forest cover. This doesn't need any particular analysis layers, and rather than filtering the data, wants the area with and without the filter. Right now you'd just have to choose a dummy analysis layer, add the contextual layer you want to rank (e.g. wdpa or adm2) and apply a tcd filter, then extract this data from the summary table.

I think it'd be way cleaner to just ask for this like:
select=wdpa, (tcd > 30) as is__forest, area

This would just return a table like:
wdpa is__forest area
0 0 435.343
0 1 4435.343
1 0 2435.343
1 1 42335.343
2 0 423435.343
2 1 343435.343
...

Then the front end can aggregate on wdpa id for total area of protected area, and by wdpa id and is__forest to get tree cover.

Then, when the front end wants a widget where they get forest loss per year, and only care about areas that hit the tcd threshold and have loss, they can ask like:
select=loss, area
where=tcd_2000 > 30 and loss != NaN

So there's no special analysis layer, you just ask explicitly ask to not include NoData values.

We also need this for complex values like emissions per year, which is actually biomass * loss_area * co2_constant. We only have the biomass as data, and right now just have a weird hook parameter to calculate this. It'd be great to do this as:
select=loss, area, (sum(biomass) * area * co2_constant) as emissions

(although that'll need pretty much full SQL parsing)