Explicitly allow associated_trip for any event type

This implements the change suggested in #289 by clarifying that any
trip-ending event can and should have an `associated_trip`, not just
`user_drop_off` events.

Since the Provider event system currently doesn't define which states
are allowed to transition to which other states, it's already
spec-compliant to follow a `reserved`/`user_pick_up` event with an
`unavailable`/`low_battery` event, and this is the most
semantically-accurate way to describe the scenario where a device shuts
down during a trip because of low battery. In this situation, the
implementer should include an `associated_trip` field in both events
so that API consumers can correctly identify these events as the
endpoints of the relevant trip.

Author: rf-

provider/README.md

@@ -276,7 +276,7 @@ Schema: [`status_changes` schema][sc-schema]
 | `event_time` | [timestamp][ts] | Required | Date/time that event occurred, based on device clock |
 | `event_location` | GeoJSON [Point Feature][geo] | Required | |
 | `battery_pct` | Float | Required if Applicable | Percent battery charge of device, expressed between 0 and 1 |
-| `associated_trip` | UUID | Required if Applicable | Trip UUID (foreign key to Trips API) required if `event_type_reason` is `user_pick_up` or `user_drop_off` |
+| `associated_trip` | UUID | Required if Applicable | Trip UUID (foreign key to Trips API), required if `event_type_reason` is `user_pick_up` or `user_drop_off`, or for any other status change event that marks the end of a trip. |
 
 ### Status Changes Query Parameters