Add KML support to conform pipeline

[iandees]

Fixes #17

Adds "kml" as a recognized conform.format value, reusing the existing OGR-based extraction path (ogr_source_to_csv) already used for shapefile/gdb/gpkg/xml(gml) sources. GDAL's built-in LIBKML/KML drivers handle the actual parsing, same as for the other OGR-backed formats.

Changes in openaddr/conform.py:

• find_source_path(): new kml branch that locates a .kml file among the downloaded source paths (mirrors the existing gpkg branch, including the "multiple candidates + file attribute" disambiguation logic).
• extract_to_source_csv(): routes kml through the same ogr_source_to_csv() call used for shapefile/xml/gdb/gpkg.
• conform_cli(): added kml to the list of recognized format strings.

What's supported

• KML Placemark elements with Point geometry and simple attribute data in <ExtendedData><Data name="..."> elements, read via GDAL's LIBKML/KML OGR driver.
• Reprojection, encoding handling, and centroid calculation all work identically to the other OGR-backed formats since they share the same code path.

Verified end-to-end with a new test (test_lake_man_kml in openaddr/tests/conform.py) using a hand-written KML fixture (openaddr/tests/conforms/lake-man.kml) containing the same 6 addresses as the existing lake-man.shp/lake-man.gpkg fixtures, with a matching conform JSON (lake-man-kml.json).

Explicitly out of scope for this first pass

• 3D/altitude coordinates. KML places allow an optional altitude in <coordinates> (lon,lat,alt). The test fixture intentionally uses 2D coordinates (lon,lat) so OGR reads plain POINT geometry, matching the 2D output of the other formats. Placemarks with an altitude component will come through as POINT Z geometry and produce a 3-element coordinates array in the output GeoJSON — this isn't tested or specifically handled.
• Non-Point geometry (LineString/Polygon placemarks, MultiGeometry) — not tested, though the shared ogr_source_to_csv path should handle them the same way it does for shapefile/gdb/gpkg polygon/line sources (used today for buildings/parcels layers).
• KML Schema/SimpleField-typed ExtendedData (the more structured alternative to plain <Data name="..."> elements) — not tested, though OGR's KML/LIBKML drivers generally support both.
• KMZ (zipped KML) — not addressed; would need its own format string and decompression handling if desired.

Verified locally with GDAL 3.11 (matching the project's Docker image): both the KML and LIBKML OGR drivers are present in the build, and the full test suite (python3 test.py, 121 tests) passes.