Keep unmatched addresses in batch geocoding responses

[imliam]

Fixes #24 - batch geocoding raised IndexError when a query returned no matches (e.g. an unparseable address). The API returns one entry per query, and unmatched ones have an empty results list, but the parser indexed results[0] unconditionally, crashing the whole batch.

This PR keeps one GeocodingResult per submitted address, in order:

• Matched queries parse as before.
• Unmatched queries come back with location=None instead of crashing or being dropped.

To make the results usable:

• GeocodingResult.location is now Optional[Location].
• Added a query field so each result can map back to the address submitted.
• Added a matched property (location is not None) as a readability helper.

The point of batch geocoding is that N number of inputs corresponds to N number of outputs. If unmatched addresses are silently dropped, like #26 and #27 do, a 100-address batch with 3 failures returns 97 results with no way to tell which 3 failed or where they were.

Keeping them preserves positional alignment and lets callers handle failures explicitly:

    resp = client.geocode(addresses)
    for r in resp.results:
        if r.matched:
            use(r.query, r.location)
        else:
            log_failed(r.query)

Backwards compatibility

Batches with all-matched addresses are unchanged (same count, same order).

Batches containing an unmatched address previously crashed, whereas now the location property is widened to Optional as a type-level change only; matched results still carry a real Location at runtime.