Reduce the amount of data uploaded to the GPU

@mourner is already working on this.

Since May 30, 2019.

One of the things that affects GL JS rendering performance linearly and that we can track reliably is the amount of data we upload to the GPU for rendering (given the same style). Specifically, the total size of data given to `bufferData` calls.

There are two directions we can explore for this — fixing older regressions and finding new ways to upload less.

### Fixing regressions

Looking at historical metrics of how much data we upload throughout previous GL JS version, I found 3 regressions:

- [ ] As a result of #3061 and #3120, we upload data for zero-opacity layers, which can significantly increase the amount of unnecessarily uploaded data for some style/zoom combinations. On z11.1 Mapbox Streets v10 sample, it's a ~12% regression.
- [x] In #5073, we had to introduce a ~25% regression to work around a GPU bug on old Android phones. @ansis believes we can win this back while keeping the bug fixed by packing normals differently. PR #8306
- [ ] #5184 has a ~5% regression ~~but I'm not sure why. Needs to be investigated.~~ due to uploading line index data for fills even if it's not needed (`fill-antialias` is `false`).

### Adding new savings

Some things we could explore from the top of my mind:

- [ ] Using instanced rendering (see also #1898) to significantly reduce vertex buffers. Should be pretty straightforward for instancing things like circles and heatmap kernels (4x reduction). It will be harder to take advantage of this for lines/fills, but we should explore possibilities.
- [x] Revisiting how we tesselate lines and seeing if we can reduce the amount of triangles generated for line joins and line caps. Related: #8275

cc @ansis @kkaefer