feat: add ArcGIS REST API fetch function

[qgolsteyn]

This PR creates a new function to fetch a JSON from an ArcGIS dashboard's REST API. It follows the suggestion from #832 by handling pagination, and the approach is compatible. I have update the SE scraper to demonstrate intended behavior. Any non-timeseries scraper will require a more significant change to avoid creating a cache-miss due to the changed URL.

[jzohrab]

This will need some work to function with the arcgis stuff currently in master. :-)

[qgolsteyn]

Thank you for all these comments, second round of review is now open :)

[jzohrab]

Please remove the coronadatascraper-cache update.

I believe that @shaperilio was looking at this as well. I'm reluctant to merge this currently, perhaps we can touch base tomorrow, @qgolsteyn , @shaperilio , and me.

[shaperilio]

I put a PR into @qgolsteyn's branch that migrates all the scrapers that would be affected.

[shaperilio]

@qgolsteyn @jzohrab @camjc @lazd pinging you folks on this PR.

@jzohrab , I believe you wanted @qgolsteyn to remove a submodule update?

Note:
I migrated every scraper that this would affect in a potentially ugly way, but so that we don't get cache misses due to different URLs. Part of this ugliness is this addition to datetime:

const ARCGIS_PAGINATION_DEPLOY_DATE = '2020-04-19'

We need to set that to the date we want these sources to start using the paginated fetch. So it has to at least be the day that we merge. If scrape date is before this date, the scrapers will use their old URLs. I believe this can all go away with li's cache architecture?

Testing:
I didn't write any tests. However, for each scraper affected, I ran a timeseries across this date boundary to ensure caching and fetching in the new way worked. This was an eyeball test, quickly checking e.g. that cases didn't plummet to zero.

[shaperilio]

See #889

[jzohrab]

Closing this PR, as the work is part of #889. Thank you @qgolsteyn !