[Feature]: Expose heading and speed on road-snapped location events

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Use case

Apps that draw their own location marker on top of the navigation session —
rather than using the SDK's own puck — need a direction to orient it by.

`RoadSnappedLocationUpdatedEvent` currently exposes only the coordinate, so the
only way to orient a marker is to infer a bearing from consecutive points. That
is unreliable at low speed and visibly wrong when stationary.

### Proposal

Expose the heading and speed the platform location already carries.

Both native callbacks receive a full platform location and forward two fields
of it:

`ios/.../GoogleMapsNavigationSessionManager.swift`

```swift
func locationProvider(_ p: GMSRoadSnappedLocationProvider, didUpdate location: CLLocation) {
_navigationSessionEventApi?.onRoadSnappedLocationUpdated(
location: .init(latitude: location.coordinate.latitude,
longitude: location.coordinate.longitude),
```

`android/.../GoogleMapsNavigationSessionManager.kt`

```kotlin
override fun onLocationChanged(location: Location) {
navigationSessionEventApi.onRoadSnappedLocationUpdated(
LatLngDto(location.latitude, location.longitude)
) {}
}
```

`CLLocation` has `course` and `speed`; `Location` has `bearing` and `speed`. The
data is already there and road-snapped — it is dropped at the Flutter boundary.

### Note on "unknown"

Both platforms have a way of saying they have no course or speed: iOS leaves
`CLLocation.course` and `.speed` negative, Android leaves `hasBearing()` and
`hasSpeed()` false. Forwarding those as `0` would read as heading due north at a
standstill, so the fields should be nullable and the absent case mapped to null.

### Package version

0.11.0