Refactor api structure

[scuerda]

The scraping targets are currently defined within a JSON that needs to be updated when changes are made. If EdSight endpoints were consistently defined and/or structured this would be reasonable, but a number of datasets have specific issues ranging from factor naming typos to alternate ways of presenting the report endpoints to the user.

For example, the state-level year-specific enrollment data is formatted closer to a print report, with multiple CSVs served from one page and subgroups disabled.

Should consider moving internal functions for generating URLs to be dataset specific and adapt a registration approach similar to what is used in the town profile proxy API. This could be handled incrementally by checking dataset by name and routing accordingly.