Don't drop partially unsupported GTFS-RT messages

[jbruechert]

Previously all messages containing unsupported fields like (alert or
vehicle) were ignored, even if they contained an understandable
trip_update.

Now all possible warnings are emitted, not just the first fatal one.

This commit also changes the debug output to show the names of the
relevant fields to make it easier to debug GTFS-RT feeds without looking
at the MOTIS source code.

[jbruechert]

Apparently the specification recommends against sending multiple types of update in one message (public-transport/transitous#689 (comment)).
Does it still make sense to be lenient on the consumer side and leave interpreting the spec strictly to the producers, or should I reduce this PR to the logging changes?

[felixguendling]

As long as there's only this one feed that is not standard conformant (and it seems like it can be changed) I would prefer to stick to the standard. So logging a warning message if the sum is != 1U would be sufficient IMO.

In case feeds we want to support but don't have any control over can be support with a small change, I would merge it.

[jbruechert]

I ran this patch on the full Transitous dataset. us-ny-MetroNorth, fr-donnees-theoriques-et-temps-reel and fr-horaires-theoriques-et-temps-reels-du-reseau-de-transports-lagglo-en-bus-communaute-dagglomeration-gap-tallard-durance have the same problem, so this does appear in the real world

[felixguendling]

Thank you very much for checking all feeds! I refactored a bit to reduce redundancy (which was already there before, not your mistake). Thank you for the PR! It's included in the v2.0 release.