A long time ago, Cesium created instances of `BingMapsGeocoderService` and
`BigMapsImageryProvider` behind the scenes by default using a demo key.
We provided the `BingMapsApi` singleton to make it easy to set a different
key in one place.
We haven't shipped with a demo key in a long time and there's really no
good reason to maintain the `BingMapsApi` singleton at the library level.
None of the `XXXGeometry` classes are actually `Geometry` instances. They
are instead utility classes that create geometries via their
`createGeometry` implementation. `GeometryInstance` can take either "type"
but since JS doesn't have types we never really defined what the "utility"
type is, so the TypeScript definition for `GeometryInstance` specifies that
currently only specifies `Geometry`. This means that this valid JS code
is a compiler error in TypeScript
```
const geometryInstance = new GeometryInstance({
geometry: new PolylineGeometry({
positions: [],
}),
});
```
To fix this, I introduced a `GeometryFactory` base class like we have
elsewhere in the code and changed `GeometryInstance` to take either type.
This is the only place where we actually base "non-geometry Geometry" in
the API.
Happy to consider other names, like `GeometryCreator` if we don't like
factory for some reason, but I want to get this in sooner rather than
later for 1.70.1 fixes.
Also fixed an issue with tsconfig.json I introduced in my last change
which was failing to actually catch TS compile errors because it wasn't
including the Cesium.d.ts.
We were including all Cesium directories in the TypeScript smokescreen
configuration. This meant that multiple Cesium.d.ts files were included
if you did a full build and then ran `build-ts` afterwards. This updates
the config used by the smokescreen to only include Source.
1. Add a Specs/TypeScript directory with a minimal TS configuration that
uses the d.ts files generated by build-ts
2. Have `build-ts` compile index.ts from this directory which makes sure
various types actually conform to their expected interfaces.
3. Fix ImageryProvider interfaces which had issues exposed by this new
test.
In the future we can add any additional smokescreens that we think are
important to validate our definitions going forward, but this will never
be a fully exhaustive check.
We currently don't actually execute the output, it's just there for
compile-time checking. We can revisit this if we ever feel that it's
needed.