feat(service): relevance-based sorting for stop search

[munterfi]

This PR improves the user experience of the /schedule/stops/autocomplete endpoint by introducing a configurable, relevance-based sorting mechanism.

The Problem

Previously, the stop search had two suboptimal behaviors:

1. searchType=STARTS_WITH was too restrictive and often returned no results for common user queries (e.g., searching "Wollis" for "Zürich Wollishofen").
2. searchType=CONTAINS with the old alphabetical sort returned irrelevant results first, burying the most likely intended stop.

The Solution

This change introduces a StopSortStrategy with a new sort query parameter, defaulting to RELEVANCE. This new strategy provides a "best of both worlds" experience by:

• Finding all stops that contain the query (CONTAINS).
• Sorting them intelligently based on relevance (exact match > starts with > contains), using name length as a tie-breaker.

The previous ALPHABETICAL sort remains available for consumers who need it.

Simple Examples

Query: Gstaa
SearchType: ``CONTAINS`

http://localhost:8080/schedule/stops/autocomplete?query=Gstaa&searchType=CONTAINS&stopSortStrategy=RELEVANCE&limit=100

Before (sort=ALPHABETICAL)	After (default sort=RELEVANCE)
1. Eggli (Gstaad)	1. Gstaad
2. Grund b. Gstaad, ...	2. Gstaad, Trom
3. Grund b. Gstaad, ...	3. Gstaad Bissen
...	...
x. Gstaad	x. Grund b. Gstaad

The new default behavior correctly and intuitively places the most relevant result, "Gstaad", at the top of the list.

[clukas1]

Nice work. We had to hack together a similar solution in our streamlit ui before, but implementing it in the backend makes much more sense and is a cleaner approach.