Use RegionAbbr for match_region with Esri WGS

[ddohler]

Overview

Previously, we were using Esri WGS's Region to populate match_region, but it provides the full name of the region, e.g. "Pennsylvania", rather than the abbrevation ("PA"), which is what most people expect, and which is contained in the RegionAbbr field. Additionally, we use the equivalent field to RegionAbbr to populate match_region with the Google geocoder ("short_name"), so the two sources provided very different data in match_region. This switches to use the RegionAbbr field for match_region with Esri WGS, which should be more user-friendly and will match the output from Google better (although neither one documents the format for their respective "short" fields, so there's no guarantee that they'll always match).

Notes

• CI may fail -- I believe I configured my local environment with the same service credentials that are in CI, and I got a consistent failure from the Esri authentication test. I'll address that if it does.
• I'd be interested to hear feedback on what the version number for the next release should be. Switching from a text description to an abbreviation of region would likely be a breaking change to anyone who was relying on the current Esri match_region behavior.
• I included a test for Google's use of short_name because the reason why this was discovered was that there was a mismatch between the Esri and Google behavior, so that seemed worth enforcing. However, I didn't try to ensure that every geocoder behaves the same way because Esri and Google are the most heavily used and not all the other geocoders are structured in a way that provides control over region abbrevations. But I could take a look at doing that if it would be valuable.

Testing instructions

• Running tests should be all that's necessary, but if you want you can revert the changes to esri.py and confirm that it triggers a failure.

[ddohler]

Where is CI?

Yep, good point -- I saw a travis.yml file in the repo and turned away after putting up the PR under the assumption that it would build, but it looks like travis-ci.org has been non-functional for about four weeks now. I signed up for a travis-ci.com account and looked into migration paths, but everything that seemed obvious also seemed like it might have organization-wide effects, so that made me reluctant to move ahead without consulting Ops, and I put in a query to them. Hopefully it'll be easy to get this moved over once they get back to me; the travis.yml syntax is claimed to be the same across both environments.

I'll drop in the Python version additions once we get this building on travis-ci.com.

[ddohler]

Update: We made the decision to shift this over to GH Actions, since it seemed pretty easy and that's our preferred solution moving forward anyway. I opened a separate PR for that work and I'll update this once that's merged. https://github.com/azavea/python-omgeo/pull/64

[ddohler]

Okay, we've got (mostly) functional CI now, and I fixed the issue with the Esri keys, so this is ready for review!