Fix more GeoJSON rasterization issues

[azrogers]

The sequel to #1256. This pull request fixes a few standing issues with GeoJSON rasterization:

• The width of the style was not being factored into the bounding box of a GeoJSON geometry primitive. This could cause issues when the width of a line means it should be considered for rendering in other tiles besides the ones the line itself is passing through, causing inconsistent rendering. However, the most common way for this issue to crop up is that a fully vertical or fully horizontal line (a line around the equator or a line around the meridian, for example) would not show up, because its bounding box height or width would be zero without the style's width being factored in. This was noted in Fix GeoJSON rasterization issues #1256.
• Geometry near the antimeridian would not render correctly, because the use of expandToIncludePosition would mean the bounding box would never encompass the full globe no matter how many points were in your document. GlobeRectangle calculation has been changed to handle this (which has introduced other far more minor issues as a result - see below). This means this PR closes GeoJSON Rasterization issues at anti-meridian #1275.
• GeoJSON points, features, feature collections, and geometry collections were being included in the quadtree, even though they will never be rendered (even if geometry they contain will). Besides wasting some memory and computation time, it meant that primitives could be rendered multiple times - first in the FeatureCollection, then each geometry individually. This caused issues with transparency.

The above issues have been fixed. In the course of doing so, we've introduced a few small edge cases which we've decided are at this point not worth the time to fix. For future reference, they are:

• Geometry set to use LineWidthMode::Meters will have its width factored in when building the quadtree instead of when rendering the quadtree. This is more efficient but can cause issues with geometry near the antimeridian. This is because we grow the bounding rectangle of the geometry based on the width in meters, but this can cause it to grow past the antimeridian and produce a rectangle which GlobeRectangle::computeUnion will mangle. The solution here is to either come up with a smarter way of growing the bounding rectangle that produces a rectangle computeUnion will accept, or handling LineWidthMode::Meters the same as handling LineWidthMode::Pixels and do it all at render time.
• The GeoJSON specification says that geometry should be cut at the antimeridian, but this is different from saying that geometry must be cut at the antimeridian. The way that other renderers like MapBox allow you to specify geometry crossing the antimeridian is to use coordinates outside the bounds of [-180, 180]. So, for example, you could create a line from -170 to -190 and this would work. This PR does not support doing this for two reasons: one, radiansToPoint in VectorRasterizer.cpp doesn't understand these coordinates, and two, CesiumGeospatial::GlobeRectangle::computeIntersection fails when one rectangle crosses the antimeridian and the other exactly touches it. #1301 means that raster overlay tiles adjacent to the antimeridian will not be considered to include the document bounding rectangle that crosses the antimeridian, even though it should.

[j9liu]

Thanks @azrogers for the fixes! Just two minor comments, otherwise this is ready to go. I tested the user scenarios you included in your writeup and they work great with this branch 👍

[j9liu]

Thanks @azrogers !