Tile coverage updates

[brunoabinader]

This PR is an extract of my last Friday Hack project - the intent is to (1) reserve an equal-or-bigger-than amount of container memory for CoverID items computed in the tileCover algorithm, and (2) raise the maximum pitch to 80 degrees.

For the latter, an heuristic is applied on tileCover to limit the view height based on the following pseudo-code:

pitch <= π / 3 ? height : height - (height * sin(pitch - π / 3)

This gives an easing curve to the height that varies conform the given pitch, with a reduction of ~33% of height's size when pitch is at ~80 degrees.

[brunoabinader]

Further changes are required to e.g. make tileCover consider neighbor tiles at the border of the view when map has a non-zero bearing:

[brunoabinader]

One reasonable idea to resolve the visible, yet far away from center tiles is to load tiles from a lower zoom level - which will cover a much bigger area with less efforts. I believe this makes sense because the lower details won't matter anyway.

[1ec5]

One reasonable idea to resolve the visible, yet far away from center tiles is to load tiles from a lower zoom level - which will cover a much bigger area with less efforts. I believe this makes sense because the lower details won't matter anyway.

More discussion in #9037. It sounds like the challenge would be avoiding inconsistencies as we cut from one evaluated zoom level to another, such as extruded buildings that get cut off at tile seams.

[brunoabinader]

Instead of limiting the coverage area based on the tilt value, we could instead adopt a threshold for the distance between the center tile and the covered tile, and if it is higher than the threshold, we notify the tile pyramid to update renderables using two separate tile vectors: one for the regular zoom tiles, and other for the lowered zoom tiles.

This approach is similar to the one proposed by @tmpsantos in #7741, and should cover the solution for tilted views proposed by @kkaefer in #9037.

[brunoabinader]

Superseded by #12310.