Handle informed trip descriptors with empty trip ids and non-empty route

[cedarbaum]

Overview

This change handles an edge case where the trip entity selector is used for providing alerts for a given route without a tripId.

For example, the MTA buses provide alerts in this form sometimes:

 {
      "id": "MTA NYCT_lmm:planned_work:9387",
      "alert": {
        ...
        "informedEntity": [
          {
            "agencyId": "MTA NYCT",
            "trip": {
              "routeId": "M14D+",
              "directionId": 1
            }
          },
          {
            "agencyId": "MTA NYCT",
            "trip": {
              "routeId": "M14D+",
              "directionId": 0
            }
          }
        ],
       ...
    },
}

In the above case, the alert effectively applies to the whole route since both directions are covered.

Note also that a tripID is not always required to uniquely identify a trip. A trip can sometimes be identified with a combination of route_id, direction_id, start_time, and start_date (see GTFS spec). If the tripID is empty but all of these fields are provided, we can consider the trip as potentially identifiable.

We therefore consider the following cases for how to handle this:

1.) An alert has informed trips with no identifiable trip instance, a routeId, and both directions are specified (one in each entity, as in the above example): consider this alert as affecting the entire route and add a route informed entity.

2.) An alert has an informed trip with no identifiable trip instance, a routeId, and no directions are specified: consider this alert as affecting the entire route and add a route informed entity.

3.) An alert has an informed trip with no identifiable trip instance, a routeId and a single direction is specified: consider this alert as affecting the route running in that direction and inform the route/direction combination.

In all 3 cases, the alert will not be associated with any trips, since a trip descriptor is required to uniquely identify a trip instance.

This change also discards informed entities for an alert that are considered of no use (i.e. they don't match any entities).

[jamespfennell]

Overall this looks good.

I think there may be some edge cases where the current code doesn't do the right thing (but we can fix these post-merge - for well behaved GTFS files this commit is a no-op).

For example, suppose the alert has two trip informed entities: one for a specific trip but identified using the other fields (i.e., route, time, direction are specified) and one of the informed entities this CL is concerned with (just has the route ID set). In this case I believe the current code, when considering the first informed entity, will set informedRoutes[routeID]=true and then when considering the second informed entity will short cirtuict via the code:

	if informedRoutes[routeID] {
			continue
	}

Of course this should be trivial to unit test, maybe I'll try myself.