Add Cesium ion geocoder to CesiumIonClient::Connection

[azrogers]

As described in #974, we want to make it easier for users to find the coordinates of locations of interest in our integrations, as an alternative to looking up the coordinates through some other service and entering them manually. The first step of this is completing #70, an implementation of the Cesium ion geocoder API, which is what this PR is for. It adds a geocode method to CesiumIonClient::Connection modeled on the CesiumJS geocoder API. This isn't a complete geocoder implementation supporting multiple services, but it will allow us to implement CesiumGS/cesium-unreal#99 to improve Cesium for Unreal's ease of use.

[kring]

Looks good @azrogers! Just some nitpicky comments here.

[kring]

Suggested change

	std::string& displayName_,
	CesiumGeospatial::GlobeRectangle& destination_)
	const std::string& displayName_,
	const CesiumGeospatial::GlobeRectangle& destination_)

[kring]

Suggested change

	std::string& displayName_,
	CesiumGeospatial::Cartographic& destination_)
	const std::string& displayName_,
	const CesiumGeospatial::Cartographic& destination_)

[kring]

Alternatively, you could do this:

GeocoderFeature(
      std::string displayName_,
      const CesiumGeospatial::Cartographic& destination_)
      : displayName(std::move(displayName_)), destination(destination_) {}

Which would be slightly more efficient because you can optionally move the string into the constructor (moving a GlobeRectangle isn't any different from copying it).

Slightly more efficient still would be two constructors, but that's almost certainly not worth the noise:

GeocoderFeature(
      std::string&& displayName_,
      const CesiumGeospatial::Cartographic& destination_)
      : displayName(std::move(displayName_)), destination(destination_) {}

GeocoderFeature(
      const std::string& displayName_,
      const CesiumGeospatial::Cartographic& destination_)
      : displayName(displayName_), destination(destination_) {}

[kring]

Another possibility here is to just get rid of the constructors entirely for these simple value-holding types. Users could still create instances with almost the exact same syntax, except they'd have to use curly braces.

[kring]

Suggested change

	GeocoderAttribution(std::string& html_, bool showOnScreen_)
	GeocoderAttribution(const std::string& html_, bool showOnScreen_)

[kring]

Generally we pass enums by value instead of const reference, cause they're just integers.

[kring]

This file is inconsistent to begin with, but we should move toward #include <CesiumHeader/Whatever.h> instead of #include "CesiumHeader/Whatever.h".

[kring]

Not a huge deal, but it'd be nice to move the rapidjson::Pointer construction outside the loop. No reason to do it repeatedly.

[kring]

What if properties.label isn't a string? It'd be safer to either check IsString, or use JsonHelpers::getStringOrDefault (which will do this for you).

[kring]

We should generally avoid logging this sort of thing directly, because it's not accessible programmatically and in some cases it might be viewed as spam. The pattern used elsewhere in this file (use the OrDefault methods to silently fill in a default if the JSON doesn't match what we expect) isn't perfect, but better to stick with that for consistency.

[kring]

It's ok to use auto for iterators, but this is more clear without:

Suggested change

	const auto& element = valueJson[i];
	const rapidjson::Value& element = valueJson[i];

[kring]

CesiumJS seems to use lowercase names, and leaves the parameter out entirely for Default:
https://github.com/CesiumGS/cesium/pull/12299/files#diff-1a5903d86aa48fe1b27e5f0d8e5da57e1afc40ee0e1ee6029fded82c23f5b1aaR28