Add optional automatic Verbundticket price fetching

[mariusangelmann]

This PR adds support for automatically fetching prices for Verbundtickets (local transport network tickets) which require a two-step API process.

Problem

Verbundtickets don't include prices in the initial journey response. Instead, they return an empty angebotsCluster and require a subsequent /angebote/recon request to fetch the actual ticket prices.

Solution

• Added optional autoFetchVerbundtickets parameter to journeys() and refreshJourney() methods
• When enabled, automatically detects Verbundtickets and makes the required recon request
• Maintains backward compatibility - feature is disabled by default

Usage

const journeys = await client.journeys(from, to, {
  tickets: true,
  autoFetchVerbundtickets: true // opt-in to automatic price fetching
})

Changes

• Added lib/fetch-verbundticket-prices.js to handle recon requests
• Modified parse/journey.js to detect and fetch Verbundticket prices when enabled
• Updated documentation for journeys() and refreshJourney() methods
• Added German terms to cspell configuration

[traines-source]

These are more philosophical things, but at least so far one request to db-vendo-client would always equal one request to a DB backend (in order to not inundate the APIs with requests and not become another bahn.expert, aggregating information from many different sources and APIs), and while we have added features/flags before that go beyond hafas-client, I think we should strive to stay close as possible to hafas-client. In some sense this is the only reason of existence of db-vendo-client, since the new DB APIs are usually at least much more readable/usable than their HAFAS counterparts... That said and you apparently seeing the need, I think we can nonetheless add the Verbundticket feature.

I'm not so fond of parseJourney becoming async. While it's not really part of the external API, I'm not sure who or what relies on it not being async (and so far it is somewhat backwards compatible with hafas-client). Also, the request logic should move into the dbnav profile and then either you reimplement the same for the dbweb profile and actual bahn.de endpoints if it's reasonably similar or you mark it as just being supported with the dbnav profile. (I think you could then have a profile-specific async function that is called after parseJourney and enriches the parsed journey with the Verbundtickets if applicable, and is a noop otherwise.) It's good that at least it doesn't fail the entire request 👍

Also, is it really the case that DB Navigator et al do a separate request for each journey with a Verbundticket? Or do they only do that in the detail view, meaning we should also only add it in refreshJourney, similar to how the different tickets are only returned in the refreshJourney endpoint? (Another reason to move it out of the parsing and into an additional call after parseJourney IMO, then only in the refreshJourney endpoint.)