Add MapViewDirections flexible location inputs (coordinate, address, place_id)

[jkasprzyk17]

Context

react-native-maps-directions accepts flexible origin and destination values — not only { latitude, longitude } objects. Supported formats include comma-separated coordinate strings, human-readable addresses, location names, and Google Place IDs prefixed with place_id:.

Reference: https://github.com/bramus/react-native-maps-directions#an-extra-note-on-origin-and-destination

<MapViewDirections origin={{ latitude: 37.33, longitude: -122.00 }} destination="…" />
<MapViewDirections origin="37.3317876,-122.0054812" destination="…" />
<MapViewDirections origin="Apple Park Visitor Center" destination="…" />
<MapViewDirections origin="10600 N Tantau Ave, Cupertino, CA 95014, USA" destination="…" />
<MapViewDirections origin="place_id:ChIJW5i0tJC1j4ARoUGtkogTaUU" destination="…" />

Google Directions API accepts these as query string values directly — no geocoding step is required server-side from our package.

Goal

Support the same location input union type for origin, destination, and waypoints entries:

type LocationInput =
  | Coordinate
  | string; // "lat,lng" | address | place name | "place_id:…"

Scope

• Define and export LocationInput type in @nitro-maps/directions.
• Normalize all location inputs to the string format expected by Google Directions API:
  • Coordinate → "lat,lng"
  • "lat,lng" string → pass through (validate format)
  • address / location name → URL-encode and pass through
  • place_id:… → pass through unchanged
• Apply normalization in fetch layer (Add MapViewDirections core — Google Directions API and route polyline #7/Add MapViewDirections advanced routing — waypoints, modes, traffic, split routes #8).
• Mixed formats allowed (origin object + destination string, etc.).
• Document that language and region props improve accuracy for localized address strings.
• Add validation errors for malformed "lat,lng" strings via onError.
• Unit tests for each input format and encoding edge cases.

Out of scope

• Client-side geocoding (Places API / Geocoding API) — consumers can geocode separately if needed.
• Reverse geocoding.
• Non-Google routing backends (Add directions example, docs, and react-native-maps-directions migration guide #10).

Acceptance criteria

• All five location formats from react-native-maps-directions docs work with a valid API key.
• Coordinate and "lat,lng" produce identical routes for the same point.
• place_id: prefix is forwarded correctly to Google Directions API.
• Malformed coordinate strings fail fast with descriptive onError.
• TypeScript types exported and documented.
• Migration note: prop naming matches bramus library (origin/destination/waypoints).

Notes

Depends on #7. Can ship in parallel with #8 if fetch layer is structured with a shared normalizeLocationInput() helper.