FlatGeobuf input improvements

[bdon]

• Streaming support. tippecanoe should accept a stream of FlatGeobuf on stdin just like GeoJsonSeq.
• tippecanoe extensions. The tippecanoe GeoJSON extension is used to specify special keys like maxzoom, but FlatGeobuf is not extensible in the same way. We should instead reproduce the same behavior for namespaced keys e.g. tippecanoe:maxzoom.
• heterogeneous files. A FlatGeobuf can have a mix of lines and polygons in a single file.
• GeometryCollection. Similar to above, but where a single FGB Feature contains multiple geometry types.
• Per-feature schemas: There currently is not any FGB writer tools that produce "Schemaless" output. The GDAL driver always outputs tabular data. This is necessary for efficiency on OpenStreetMap data and to have parity with GeoJSON input.

[1papaya]

Would you all consider adding support for gzipped FlatGeobuf's just like is possible with GeoJSON's? Compressing FlatGeobuf's reduces the filesize considerably which could be useful for some applications with a large volume of input data

[bdon]

@1papaya I would prefer that instead we implement streaming support for FGB. That would allow you to stream data through a decompressor first and then pipe into tippecanoe. Additionally, it would allow for more efficient alternatives to gzip like LZ4 or ZSTD.