add block_group_id to trips.txt and deadheads.txt

[BTollison]

This is a proposal to add block_group_id to trips.txt and deadheads.txt, and block_id to deadheads.txt. The intention to is to handle the need to group blocks together when you are using EV's. Traditionally, a block_id can cover either the entire string of trips for a specific vehicle over a day or model the peak work. It does not have to show what 1 vehicle will do for an entire day. This becomes important when trying to keep track of the amount of energy in a battery for a given vehicle.

block_id
Add to deadheads.txt to keep trip of which block is part of a deadhead.

block_group_id
A unique integer value per service_id, which helps group together all events that 1 physical vehicle does on a single service day.

[safrazier17]

1. Addition of block_id to deadheads.txt is unnecessary based on changes in proposal Supplementing Public GTFS data (trips, stops, stop_times, routes, etc.) within ODS #55
2. Addition of block_group_id to trips.txt cannot be effectuated by ODS
3. Addition of (ods_)block_group_id to proposed trips_supplement.txt could be effectuated by ODS

Would (3) be useful / could it satisfy the use case laid out here? @BTollison @skyqrose @jeffkessler-keolis

[jeffkessler-keolis]

(3) would satisfy the use case here, and I believe could be valuable. The rail side often primarily matches trips to equipment in "cycles," which are often combinations of blocks in scheduling systems (i.e. the same as the block_group_id proposed).

I'm fine adopting ods_block_group_id as a standard ODS field for trips — the alternative being that we each use our preferred nomenclature e.g. "ods_cycle_id" on our end with the same functionality across producers.