Required type of transportation at `routes` level may lack flexibility (multi-modal routes)

The French regional railways [TER](https://en.wikipedia.org/wiki/Transport_express_r%C3%A9gional) operates both trains and buses on regular routes all over the country. They do publish a GTFS dataset daily: [https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip](https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip)

Some routes are designed to be operated with both trains and buses depending on the trip. You can download a human readable (PDF) schedule for such a route [here](https://ter-fiches-horaires.sncf.fr/publish/A19%20et%20cars%20Colmar%20Metzeral%20%28du%2021%20ao%C3%83%C2%83%C3%82%C2%BBt%20au%209%20d%C3%83%C2%83%C3%82%C2%A9cembre%202023%29%20MAJ%201008.pdf) (fr).
On the schedule table of the first page, the `12:44`, `20:28` and `22:00` trips are clearly identified with a blue bus icon () which is defined in the legend as regular trip carried out with bus. I insist, those are not exceptions (that could be handled through GTFS-RT).

In the current GTFS specification, the "type of transportation" is a `routes` attribute and as such, cannot *elegantly* handle such use case.

## Workarounds
There are few ways around this (that I can think about) but none of them are without drawback (technically or semantically).

1. **Route duplication**: create one route regrouping the "train trips" and one route the "bus trips". Somehow it is kind of what they are doing in the PDF version of their schedules. If you scroll down to the last pages you will notice that after the general "Route 19" schedule there is a specific section for a "Route 119" that only shows bus trips.
They do that to precisely explain to the user where the bus stops are relative to the train station. Usually very close (few meters) but sometimes a bit further.
However they still chose to include the bus trips in the general schedule of "Route 19" because semantically **it is the same route** and people might not bother scrolling down few pages to find the additional trips.

2. **Loose use of `routes.route_type` (breaking the specs)**: that's actually what they implement in their GTFS dataset. That particular route is marked with a `2 / Rail` value (because it is mostly carried out by trains I suppose) but they do encode the actual type of transportation within their `stops.ID` pattern. For instance, at the same station, they'd have a `StopPoint:OCETrain TER-87182394` stop and a `StopPoint:OCECar TER-87182394` stop. Then, as a GTFS consumer, one can infer the type of transportation by checking that all stops along the trip are `*OCETrain*` or `*OCECar*` (*car* means bus in French).
_Note:_ Although technically, having to read the whole stops sequence to infer transportation type is not ideal, I find it very interesting and somehow legitimate for the type of transportation to be a `stops | location_type=0` attribute actually: after all, "train stops" and "bus stops" are very commonly distinguishable entities from the *real world*.

## Suggestions for modification of the specs
* Implement a way to *relate* routes together, so in this example the "route duplication" workaround could be addressed properly.
* Implement type of transportation overriding scheme at `trips` level (see #358) or at `stops` level as in the second workaround. Such a overriding would mean to specify the `routes.route_type` to be a **default value** and/or to add a "Mixed" value to the enum and handle the necessary conditional requirements.