7664 refactor geocoding

This deals with #7664, #7643, and #7640.

It refractors the Geocoding process substantially, using a ```Place``` class to represent the dpla:Place objects from DPLA MAP and hold their data for enhancement.  It also creates a common interface for geocoder enhancements in the form of ```enrich_place()```, allowing geocoders to be used interchangeably in ```Place```'s  ```enrich_geodata()``` method.

Later commits deal with the various issues in the above tickets by emphasizing Geonames, and its place hierarchies over Bing. Mainly, this:
  - Removes coordinates from the name field, instead looking them up and enhancing them.
  - Reorders transposed coordinates when they can be identified as out-of-range.
  - Merges place hierarchies that are represented in separate spatial fields into a single place value.
  - Prevents countries from serializing their coordinates, and from being geo-enhanced into a smaller administrative division near the center of the country.

General enhancement should also be improved, as represented in changes to several of the test cases:
  - "New York, NY" is enhanced (though not as well as we might achieve with some pre-parsing of name strings.
  - Provided city and state values are checked against each other and enhanced.
  - Smaller divisions (city/state) are used before country or region for enhanced values.
  - and (again) countries are prevented from being identified as smaller units within their borders.
Sure, that's no problem; in that case there would be a `place` module with a Place class for the stuff data needs to be passed around with an instance with its own internal data, or that might want to be subclassed, versus functions that can be called like `place.function()`

A lot of the Python modules just work like that and it's part of the "flat is better than nested" Python aphorism.