Add feed id column to path results

[ansoncfit]

This PR addresses #920, adding a column for feedIds to CSV path detail results. It also adds a "group" column to these results, reserved for future use. As noted in the discussion below and in #920, we are deriving the feedId from the boarding stop for convenience; this should generally correspond with the feedId of the route, but it may not (if, for example, a route has been subject to a reroute modification sending it to a stop from a different feed).

Because of some clumsy rebasing, the diff here looks larger than it is. See instead dev...results-with-feedids

[abyrd]

As recently discussed: the number of fields will remain fixed. The feed ID field will always be present, but will be empty unless it is intentionally switched on. That is, it won't be automatically enabled even when there are multiple feeds in a bundle. It will be enabled using the "flags" approach demonstrated in #930.

I'm starting to wonder though whether this merits a structured CsvOptions in the request:

{
  csvOptions: {
    stopRepresentation: ID_AND_NAME,
    routeRepresentation: NAME_ONLY,
    includeFeedIds: true
  }
}

While we're already considering increasing the hard-wired number of columns, I'd like to suggest adding another empty-by-default field called "label" or "group", which would be used to facilitate filtering and grouping CSV output rows in specialized use cases (such as select-link).

[abyrd]

A few comments on the current implementation discussed during the call:

• EntityRepresentation is ignored (we only check if it's null) - we always show the ID (not name) for now
• FeedId is that of the boarding stop, which is usually the same as the feedId of the alighting stop and the route, but might be mismatched if modifications have mixed routes and stops from different feeds
• We are grabbing the feed ID from the stop rather than the route (which might seem like a better representative of the leg) because stops happen to have a readily available feed ID

The merge-base changed after approval.

[abyrd]

Looks good (when looking at the alternate diff view you linked to). I wish I understood better why the default diff ends up looking this way due to a rebase, but hopefully the merge will work correctly.

The merge-base changed after approval.

[abyrd]

Something strange is going on with the review process:

Even if I approve it Github says a review is required. When I do a git diff from this branch to dev locally, I see the expected set of changes which is different than the changes visible here.

[abyrd]

Superseded by #936 to overcome apparent bad state on the Github side.